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_3  This  thesis  examines  the  viability  of  a  microcomputer 
based  process  which  allows  its  terminal  to  become  a  terminal 
to  a  remote  host  which  utilizes  the  UNIX  operating  system. 

The  means  of  communication  to  the  remote  host  is  an  Ethernet 
local  area  network. 

The  preponderance  -of  the  software  to  accomplish  the 
remote  login  is  ?L/I  thus  enabling  the  software  to  be 
utilized  by  any  combination  of  computer/operating  system 
that  supports  PL/I.  The  Ethernet  driver  makes  use  of  ! 

assembly  language  in  order  to  program  the  Ethernet 
Controller  Board  and  is  therefore  dependent  upon  the 
underlying  microprocessor. 

Although  the  communications  medium  is  the  Ethernet, 

ARPANET  Internet  and  Transmission  Control  protocols  are  also 
utilized.  This  is  necessitated  by  the  manner  in  which  the 


UNIX  operating  system's  remote  login  process  operates  and 
allows  the  far  more  general  case  where  the  remote  host  is 
part  of  the  ARPANET.^ 
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I.  INTRODUCTION 


A.  BACKGROUND 

AEGIS  is  a  highly  sophisticated  weapons  system  designed 
to  safeguard  a  surface  fleet  against  enemy  aircraft  and 
missiles.  An  integral  part  of  the  system  is  the  SPY-1A 
radar;  it  feeds  its  data  to  a  Navy  standard  AN/YUK-? 
computer . 

The  AEGIS  weapons  system  simulation  project  is  an 
ongoing  study  being  conducted  at  the  Naval  Postgraduate 
School.  Its  primary  objective  is  to  study  the  feasibility 
of  replacing  the  present  four-processor  AN/YUK-?  mainframe 
computer  with  a  multi-microcomputer  based  architecture. 

The  AEGIS  weapon  system  must  process  in  real-time  large 
amounts  of  data  concerning  target  detection  and  acquisition. 
In  order  to  distribute  the  data  among  the  many  micro¬ 
computers,  high  speed  data  communication  means  are  needed. 
The  high  speed  data  transfer  can  be  accomplished  by  tying 
clusters  of  MULTIBUS  connected  micro-computers  to  each  other 
by  means  of  a  local  area  network  such  as  Ethernet.  The  10 
megabit  per  second  data  transfer  rate  over  a  maximum  of  2500 
meters  of  cable  makes  Ethernet  a  powerful  data 
communications  medium  which  replaces  a  complex  system  of 
point  to  point  cables  with  a  single  cable. 
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In  order  to  create  a  useful  program  development 
environment  for  the  AEGIS  Modeling  Project,  it  is  convenient 
to  access  more  powerful  processors  located  outside  of  the 
micro-computer  cluster  hut  connected  to  the  same  Ethernet. 
The  UNIX  operating  system  has  been  popular  on  mini-computers 
and  is  becoming  much  more  commonplace  on  the  newer,  more 
powerful  micro-computers  and  is  thus  a  natural  candidate  for 
a  remote  login  from  a  terminal  connected  to  the  micro¬ 
computer  cluster. 

Initial  groundwork  in  the  AEGIS  project  for  the 
connection  of  micro-computers  to  more  powerful  processors 
using  the  Ethernet  was  conducted  by  Stotzer  [Ref.  1]  and 
Netniyom  [Ref.  2].  Stotzer,  working  at  the  micro-processor 
end,  and  Netniyom,  working  at  the  other  end  with  a  VAX 
ll/7ea  VMS  operating  system,  implemented  message  passing  and 
file  transfer  routines.  As  VMS  did  not  provide  for  a  remote 
login  as  an  integral  part  of  the  operating  system,  the 
communication  terminated  at  the  VAX  end  in  one  of  the  device 
files,  thus  reouiring  one  "hard  wired'’  terminal  from  the 
system.  A  hoped-for  virtual  communication  therefore  became 
in  essence  a  hard  wired  connection  over  the  Ethernet. 

B.  GENERAL  DISCUSSION 

The  Eerkeley  4.2  version  of  the  UNIX  operating  system 
'4.2  BSD)  in  use  at  the  Naval  Postgraduate  School  runs  on  a 
VAX  11/78?  which  is  connected  to  an  Ethernet.  Since  this 


being  necessary  in  a  local  area  network.  It  is  a  collection 
of  automonous  computers  and.  other  resources  that: 


geographically  are  within  about  2500  meters  of  one 
another! 

have  a  relatively  high  bandwidth,  usually 
ranging  from  1  to  10  million  bits  per  second! 

low  cost! 

capability  to  support  up  to  several  hundred 
connections  of  devices  on  the  network; 

low  error  rates,  high  reliability,  and  independence 
from  a  centralized  control; 

ease  of  installation  and  extensibility! 


Figure  2.3 


ARPANET  Protocol  Hierarchy 


2.  Why  local  Area  Networks 

There  are  several  reasons  for  the  high  interest  in 
local  area  networks.  Organizations  today  may  have  many 
computers  and  peripherals  located  within  the  same  or 
adjacent  buildings.  Cost  and  performance  considerations 
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transfer  Into  or  out  of  the  IMP  to  the  host  link  or 
subnetwork.  These  two  protocols  do  not,  however,  provide 
reliable  host  to  host  peer  communication  across  the  network. 
This  all  important  function  is  provided  by  the  ARPANET 
internet  protocol  and  transmission  control  protocol,  IP/TC?. 
The  protocols  will  be  discussed  in  depth  later  in  this 
thesis.  they  form  the  major  part  of  the  communications 
format  that  takes  place  in  the  remote  login  facility  of  4.2 
ESD  UNIX.  A  less  robust  host  to  host  protocol  can  be  formed 
by  combining  the  same  internet  protocol  with  the  User 
Datagram  Protocol,  UDP.  This  protocol  provides  a  procedure 
for  application  programs  to  send  messages  to  other  programs 
with  a  minimum  of  protocol  mechanism.  It  is  transaction 
oriented,  and  delivery  ar.d  duplicate  protection  are  not 
guaranteed.  Applications  that  reouire  an  ordered  delivery 
of  streams  of  data  should  use  the  TCP  vice  the  UDP  protocol. 

Above  these  layers  in  the  ARPANET  model  are  the 
application  or  service  layers  and  protocols  such  as  telnet 
(the  virtual  terminal  protocol),  ftp  (file  transfer 
protocol),  sftp  (simple  file  transfer  protocol),  etc.. 
Figure  2.2  shows  the  ARPANET  protocol  relationships. 

C.  LOCAL  AREA  NETWORKS 

1  •  ion 

A  local  area  network  is  best  defined  by  listing 
some  of  the  requirements  that  are  generally  accepted  as 
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ISO  Versus  ARPANET  Layers 


the  Defense  Advanced  Research  Projects  Agency,  money  was 
provided  to  selected  universities  and  private  firms  to  set 
up  an  experimental  four  node  network.  It  became  operational 
in  1969.  It  has  since  expanded  to  over  130  nodes  that  span 
the  globe.  Because  of  the  length  of  time  it  has  been  in 
existence,  the  monies  provided  for  continuing  research,  and 
the  sponsorship  by  a  powerful  backer,  the  ARPANET  is  the 
most  significant  network  in  the  world.  Much  of  the  current 
day  knowledge  about  networks  can  be  traced  to  the  ARPANET 
development . 

2.  ARPANET  Layers 

The  networking  layers  of  the  ARPANET  do  not 
correspond  in  a  one-to-one  manner  with  those  of  the  ISO 
standards.  Figure  2.2  shows  the  ARPANET  layers  and  their 
relation  to  the  ISO  standard  layers.  The  ARPANET  protocols 
are  grouped  into  four  major  categories:  network  backbone, 
network  access,  host  to  host,  and  application  or  service 
protocols.  Each  of  these  is  independent  and  optimized  for 
its  special  function  and  may  contain  several  protocols 
embedded . 

The  network  backbone  protocols  are  the  IMP-IMP 
protocols,  routing  protocols,  and  end-end  protocols,  network 
access  protocols  define  the  interface  between  a  host 
computer  and  the  switching  nodes ( IMP 's  ) . 

The  above  protocols  are  interface  protocols  between 
IMP's  and  the  host  computer.  They  permit  reliable  data 
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also  routes  incoming  messages  to  the'  correct  process  or 
connections  within  the  host  and  reassembles  messages  by 
delivering  to  the  next  higher  level  the  parts  of  messages  in 
the  correct  order,  which  is  not  necessarily  the  order  in 
which  the  messages  were  received. 

The  session  layer  provides  the  users  interface  in  the 
network.  It  provides  the  establishment  of  a  connection  with 
a  process  on  another  machine.  Once  the  connection  has  been 
established,  it  controls  the  buffering  of  data,  the  data 
transfer,  and  the  graceful  or  abrupt  closure  of  the 
connection. 

The  function  of  the  presentation  layer  is  to  negotiate 
the  syntax  for  characters  as  data,  text  strings,  terminal 
display  formats,  and  so  on.  This  layer  would  also  provide 
for  data  encryption  should  that  be  necessary. 

The  function  of  the  application  layer  is  largely 
determined  by  the  user.  It  can  provide  for  such  functions 
as  login  procedures  and  passwords.  Here  the  type  of  service 
to  the  user  is  defined?  i.e.,  is  the  transaction  a  file 
transfer,  data  transfer,  remote  login,  financial 
transaction  ,  etc  .  . 

3.  TH3  ARPANET 

1.  Background 


The  Department  of  Defense  started  the  funding  of 
research  into  computer  networks  during  the  1960's.  Through 


into  a  line  that  appears,  to  higher  protocols,  to  he  free  of 
transmission  errors.  This  layer  adds  flags  to  denote  the 
beginning  and  ending  of  messages,  utilizes  error  checking 
algorithms  are  utilized,  and  distinguishes  data  from  flags. 
Also,  this  layer  deals  with  the  problems  of  acknowledgements 
and  of  flow  control  (a  fast  sender  swamping  a  slow 
receiver). 

The  function  of  the  network  layer  is  to  control  the 
operation  of  the  subnet,  the  lower  three  layers.  It 
determines  the  routing  to  the  destination,  prevents 
congestion,  and  breaks  large  packets  into  smaller  ones  if 
they  are  too  large  for  a  particular  link,  and  handles  flow 
control  within  the  network.  The  network  layer  may  provide 
either  datagram  service  or  virtual  circuit  service. 
Datagram  service  delivers  to  the  next  higher  layer  the 
messages  from  the  transport  layer  without  ordering  the 
messages?  each  is  considered  an  isolated  unit.  The  virtual 
circuit  service  presents  the  transport  layer  with  ordered 
messages.  For  commercial  networks,  this  layer  contains  the 
accounting  algorithms  for  the  billing  of  customers. 

The  function  of  the  transport  layer  is  to  ensure  host  to 
host  error  detection  and  recovery,  control  the  size  of 
messages  passed  to  the  next  lower  level  (some  long  messages 
might  have  to  be  broken  up  into  shorter  length  messages), 
multiplex  the  end  user  address  onto  the  network,  and  the 
establishment/release  of  connections  across  the  network.  It 
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layer  as  the  data  passes  through  it.  It  is  from  this  layer 
that  the  data  is  actually  moved  to  another  node  on  the 


network  by  some  physical  link,  hardwire,  microwave,  etc.. 
At  the  destination  node,  the  data  ascends  through  the 
layers,  losing  the  bits  added  by  the  source  node  layers, 
until  it  reaches  the  destination  application  layer.  Each 
layer  can  be  pictured  as  requesting  services  from  the  layer 
beneath  it  and  providing  services  for  the  layer  above  it. 

The  importance  of  this  layered  concept  is  that  functions 
associated  with  a  network  connection  can  be  grouped  together 
in  independent  software  modules  that  handle  only  the 
functions  of  one  particular  layer.  Should  the  peer  to  peer 
protocols  change,  then  only  the  one  software  module 
associated  with  that  layer  need  be  altered. 

6 .  Junctions  of  tfce  Layers 

The  first  of  the  seven  ISO  layers  is  the  physical 
layer.  Its  function  is  the  transmitting  of  raw  bits  of  data 
over  a  communication  channel.  The  protocol  at  this  layer 
must  ensure  that  if  the  source  transmits  a  binary  1,  then  a 
binary  1  is  received  at  the  destination.  It  accomplishes 
this  by  handling  electrical  voltages  and  electrical  pulses, 
cables,  and  connectors.  The  Ethernet  physical  layer  uses 
the  protocols  known  as  Carrier  Sense  Multiple  Acces(CSMA)/ 
Collision  Detection  (CD). 


The  function  of  the  data  link  layer  is  to  take  the  raw 
transmission  provided  by  the  physical  layer  and  transform  it 


very  modular  In  nature.  Also,  the  explosive  growth  of 
networks  has  made  the  adoption  of  standards  by  all  involved 
of  paramount  importance.  An  effort  to  simplify  production 
of  and  changes  to  neworking  software  hy  standardizing  the 
modularity  of  the  software  is  found  in  the  seven  layered 
approach  as  espoused  by  the  International  Standards 
Organization  (ISO).  Figure  2.1  shows  the  ISO  standard  layer 
approach  to  communication  from  one  node  to  another  over  a 
network . 

Network  communication  commences  when  a  user  at  one  node 
interfaces  with  the  top  layer,  the  application  layer.  This 
layer  then  communicates  with  the  same  layer  in  the 
destination  node  by  what  is  called  a  peer  to  peer  protocol. 
A  protocol  is  a  communication  convention  between  equivalent 
layers  in  the  source  and  destination  hosts.  This  is  a 
virtual  communication;  actually  the  application  layer 
interfaces  with  and  makes  use  of  the  services  provided  by 
the  next  lower  layer,  the  presentation  layer.  This  layer 
communicates  to  the  presentation  layer  in  the  destination 
host  by  means  of  the  presentation  layer  peer  to  peer 
protocol.  As  before,  this  is  a  virtual  connection?  the 
actual  communication  by  the  presention  layer  is  to  the  next 
lower  layer.  The  actual  communication  continues  down 
through  the  layers  until  it  reaches  layer  1,  the  physical 
layer.  The  data  to  be  transferred  ends  up  at  the  lowest 
level  surrounded  by  various  extra  bits  appended  by  each 


for  running  user  (application)  programs.  The  specialized 
computers  that  perform  the  switching  necessary  in  a  network 
are  called  IMF's,  interface  message  processors.  A  link  is 
the  physical  communication  medium  used  to  pass  data  from  one 
IMP  to  the  neit  IMP  in  the  network.  A  typical  session  on  a 
network  might  have  the  user  wanting  to  send  a  message  to 
another  person  in  a  distant  location.  The  user  would  sit 
down  at  his  host  computer  and  generate  his  message  which 
would  he  communicated  to  the  IMP  which  actually  puts  the 
message  onto  the  network  link  to  the  destination.  The  users 
data,  assuming  it  is  a  short  message,  would  he  transmitted 
across  the  network  in  a  packet,  the  basic  unit  of 
information  that  moves  over  the  network.  A  packet  switched 
network  is  one  in  which  the  packet  can  very  greatly  in  size 
and  a  source  to  destination  path  need  not  he  established 
before  the  packet  is  sent  on  its  way.  For  instance,  two 
packets  from  the  same  host  to  the  same  destination  may  leave 
the  source  host  one  right  after  the  other  hut  take  a 
different  route  to  the  destination  host.  The  first  packet 
transmitted  from  the  source  host  may  not  he  the  first  to 
arrive  at  the  destination. 

5.  Network  Layers 

Networks,  especially  long  haul  networks,  are  very 
complex  and  reouire  elaborate  software  to  make  them  run 
effectively.  In  order  to  allow  for  rapidly  changine 
technology  and  protocols,  the  design  of  software  must  he 


in  that  there  is  no  master/slave  relationship  between  any  of 
the  computers  on  the  network. 


3 .  Aims  of  a  Network 

The  growth  of  networks  over  the  last  decade  has 
been  spectacular.  This  drift  away  from  large,  centralized 
computer  systems  is  caused  by  the  many  economic  and 
performance  advantages  of  networking.  By  using  a  network, 
all  resources  (data,  programs,  processors,  etc.)  on  the 
network  are  potentially  available  to  anyone  using  the 
network  regardless  of  the  physical  proximity  of  those 
desired  resources.  Computing  systems  can  be  made  mucn  more 
reliable  with  the  utilization  of  networks  since,  should  one 
part  of  the  system  break  down,  other  parts  can  take  up  the 
load.  Thus  systems  can  degrade  in  capability  gracefully 
rather  than  catastrophically.  Since  the  cost  of  computers 
has  declined  dramatically  while  the  cost  of  communication 
has  remained  stable,  it  now  makes  more  sense  to  do  much  more 
processing  of  data  locally  and  then  communicating  only  the 
results  to  a  central  location  rather  than  sending  all  data 
to  a  central  point  for  all  processing  needs.  In  essence, 
the  tremendous  needs  generated  by  the  information  age  are 
more  easily  fulfilled  by  the  utilization  of  networks. 

4.  Networking  Terms 

Some  definitions  of  basic  networking  terms  are 
needed  before  continuing  the  discussion.  Hosts  are  the 
various  machines  located  on  the  network  which  are  intended 
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II.  NETWORKS 


A.  NETWORKS:  GENERAL  DISCUSSION 

1.  Background 

The  4.2  BSD  UNIX  implements  the  remote  login  in  a 
manner  that  is  general  enough  to  enable  one  to  login  to  a 
remote  host  computer  over  a  local  area  network  (LAN),  a  long 
haul  network  such  as  the  ARPANET,  or  any  combination  of  the 
two.  Thus  it  would  be  possible  to  remotely  login  from  one 
UNIX  system  to  another  by  using  a  local  area  network  to  a 
node  located  on  a  long  haul  network,  thence  over  the  long 
haul  network  to  a  remote  host  that  is  also  running  4.2  BSD 
UNIX.  In  such  a  case  the  remote  login  request  would  be 
surrounded  by  both  LAN  protocols  and  long  haul  network 
protocols,  specifically  ARPANET  protocols.  In  order  to 
analyze  the  remote  login  conversation  between  two  UNIX 
systems,  some  basic  knowledge  of  networks  is  necessary. 

2.  Ce f i ni t ion 

A  computer  network  is  an  interconnection  of 
autonomous  computers.  The  interconnection  can  be 
accomplished  by  a  variety  of  means  ranging  from  hardwired 
conections,  micro-wave  connections,  or  even  satellite 
connections?  in  fact,  some  large  networks  might  employ  all 
methods  of  connections  at  one  link  or  another  within  the 
network.  The  computers  should  be  thought  of  as  autonomous 
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Chapter  III  covers  specific  information  on  the  MULTIBUS 
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based  computers  communicate  over  the  Ethernet  when  remotely 
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Chapter  VI  presents  the  conclusions  of  the  thesis. 


version  of  UNIX  implements  networking  software  facilities, 
device  drivers  for  networking  hardware,  and  a  remote  login 
capability,  the  feasibility  of  remote  terminal  login  over 
Ethernet  to  a  more  powerful  remote  host  from  a  micro¬ 
computer  was  investigated.  The  extension  beyond  Stotzer's 
and  Netniyom's  work  was  important  since  many  users  could 
remotely  use  the  VAX  11/780  over  just  one  communication 
medium,  Ethernet,  without  using  any  of  the  hardwired 
terminal  connections  to  the  remote  host.  The  method  of 
investigation  used  was  to  capture  for  analysis  the  Ethernet 
communications  between  a  Sun  Workstation,  running  4.2  BSD 
UNIX,  and  a  TAX  11/780,  also  running  4.2  BSD  UNIX. 

C.  STRUCTURE  OF  TEE  THESIS 

Chapter  I  presents  some  background  information  on  the 
AEGIS  project  here  at  the  Naval  Postgraduate  School  and 
prior  work  to  facilitate  micro-computer  communication  with 
more  capable  processors  over  an  Ethernet  connection.  It 
also  discusses  the  continuing  effort  to  enhance  such 
communication  by  being  able  to  remotely  become  a  terminal  to 
a  VAX  11/780  from  a  micro-computer. 

Chapter  II  will  discuss,  in  a  rather  general  manner,  the 
topics  cf  networks,  the  ARPANET  network,  and  the  relation 
between  the  ISO  standards  for  networks  and  the  manner  in 
which  the  ARPANET  is  implemented.  Information  of  local  area 
networks  and  Ethernet  will  also  be  presented.  Some 
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demand  that  most  if  not  all  of  these  devices  he  tied 
together  over  some  communication  medium.  The  most  efficient 
manner  of  interconnection,  rather  than  a  maze  of  "hardwired” 
connections,  is  a  local  area  network  utilizing  a  high 
bandwidth  physical  cable.  Each  computer  or  peripheral  is 
then  attached  to  the  channel  over  a  very  short  physical 
connection,  a  distinct  advantage  of  a  local  area  network  is 
its  ability  to  more  effectively  and  efficiently  perform 
distributed  computing  tasks.  This  allows  specific  functions 
such  as  file  storage,  data  base  management,  terminal 
handling  and  so  on  to  be  assigned  to  specific  machines  thus 
simplifying  implementation. 

Local  area  networks  have  several  factors  that  make 
their  implementation  much  easier  than  long  haul  networks. 
The  routing  algorithms  can  be  as  simple  as  broadcasting  all 
messages.  The  routing  algorithms  on  long  haul  networks  can 
become  extremely  complex,  especially  when  one  network  is 
tied  into  other  networks.  Local  area  networks  do  have 
potential  congestion  problems,  but  they  are  minor  compared 
to  those  that  can  be  encountered  on  long  haul  networks. 

Local  area  networks  can  sense  congestion  because  they 
sense  the  state  of  the  broadcast  channel  before  attempting 
to  use  it.  Two  of  the  types  of  local  area  networks  are  the 
carrier  sense  networks  and  the  ring  networks;  each  type  has 
a  unique  method  of  sensing  the  state  of  the  network.  The 
carrier  sense  method,  when  it  has  data  to  send,  listens  to 


the  channel  to  see  if  anyone  else  is  broadcasting.  If  the 
channel  is  busy,  the  station  waits  until  the  channel  becomes 
idle.  Once  it  has  sensed  an  idle  channel,  it  transmits  all 
or  part  of  its  data  in  a  packet.  If  a  collision  occurs  with 
another  unsensed  packet,  thus  corrupting  the  transmission, 
the  station  waits  a  random  amount  of  time  and  then  starts 
the  process  over  again.  The  ring  networks,  like  the  carrier 
sense  networks,  use  twisted  cable,  coaxial  cable,  or  fiber 
optics  as  the  transmission  medium?  however,  the  ring  net  is 
a  series  of  point  to  point  cables  between  consecutive 
stations.  The  basic  method  of  the  control  of  network 
congestion  is  through  a  token  system.  Each  node  wishing  to 
transmit  must  have  a  ticket  or  token  in  order  to  use  the 
network . 

3 .  Ethernet 

Ethernet  is  a  local  area  network  specification 
developed  by  Digital  Equipment  Corporation,  Xerox 
Corporation,  and  Intel  Corporation.  It  is  designed  for  the 
high  speed  data  exchange  among  computers  and  other  digital 
devices  located  within  a  moderately  sized  geographical  area. 
The  Ethernet  specification  pertains  to  the  first  two  layers 
of  the  ISO  model,  the  physical  and  data  link  layer.  It 
provides  for  a  data  transmission  rate  of  1?  million  bits  per 
second  over  a  coaxial  cable  with  a  maximum  length  of  2.8 
kilometer.  It  supports  up  to  1224  stations  with  a  topology 


of  a  branching  non-rooted  tree.  The  link  control  is 
CSMA/CD. 

4.  Ethernet  Frame  Format 

a.  General 

The  Ethernet  frame  consists  of  the  following 
five  fields:  the  destination  address,  the  source  address, 
the  type  field,  the  data,  and  finally  the  frame  check 
seauence.  The  64  bit  preamble  used  for  receiver 
synchronization  is  not  available  to  the  user. 

b.  Destination  address 

The  six  byte  destination  can  be  one  of  three 
types  of  addresses.  It  can  be  the  physical  address  of  a 
board?  this  address  is  unique  to  each  board  interfacing  on 
the  Ethernet;  its  first  three  bytes  are  assigned  by  Xerox 
and  the  last  three  by  the  board  manufacturer.  It  could  also 
be  a  multicast  address;  this  board  can  be  user  programmed  to 
contain  up  to  64  different  multicast  addresses.  All  board? 
receive  broadcast  packets. 

c.  Source  address 

The  physical  source  of  the  particular  board  is 
automatically  inserted  upon  packet  transmission.  This  can 
be  circumvented,  as  will  be  explained  later. 

d.  Type  field 

The  two  byte  type  field  contents  are  net 
specified;  the  user  can  use  it  for  whatever  purpose  he 
desi res . 
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III.  NPS  FACILITIES 


A.  BACKGROUND 

The  system  used  at  the  Naval  Postgraduate  School  to 
investigate  the  viability  of  the  remote  login  over  Ethernet 
was  composed  of  the  following  components:  the  AEGIS  Project 
multi-user  system,  a  Sun  Workstation  and  a  7AX  11/780,  both 
running  4.2  BPS  UNIX.  All  components  of  the  system  were 
connected  by  an  Ethernet.  Figure  3.1  shows  an  overview  of 
the  system.  The  makeup  of  the  AEGIS  multi-user  system  is 
shown  in  Figure  3.2.  Its  MULTIBUS  backplane  contains  four 
Intel  86/12  Single  Beard  Computers,  two  additional  memory 
boards,  and  an  Interlan  Ethernet  Controller  Beard.  Each 
86/12  SBC  is  attached  to  its  own  terminal.  Secondary 
storage  for  the  system  is  provided  by  two  hard  disk  drives 
and  two  floppy  disk  drives.  Some  basic  knowledge  of  the 
multi-user  system  components  is  necessary  for  the 
understanding  of  the  programs  contained  in  this  thesis. 

B.  MULTI-USER  SYSTEM  COMPONENTS 

1 .  Intel  86/12  Single  Board  Computer 

The  86/12  SBC  contains  all  the  components  necessary 
for  a  computer  on  a  single  board;  it  contains  an  6086  16-bit 
microprocessor,  64K  bytes  of  onboard  RAM,  a  serial 
communications  interface,  a  programmable  interrupt 


controller,  and  a  programmable  timer..  It  also  contains  the 
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circuitry  necessary  for  the  use  of  the  board  on  a  MULTIBUS 


system.  The  board  is  configured  so  that  it  car.  act  either 
as  a  MULTIBUS  slave  board  or  as  a  master  board  and  can 
accept  user  provided  ROM  of  up  to  32K  bytes.  All  of  the 
onboard  RAM  is  accessible  to  offboard  components  if  the 
board  is  unstrapped;  or,  conversely,  none  of  the  onboard 
memory  can  be  accessed  from  offboard  components  if  the  board 
is  strapped.  The  ability  to  allow  or  disallow  access  to 
onboard  memory  (strapping)  is  a  convienent  feature  of  the 
SBC  that  makes  it  very  useful  in  multi-processing 
installations.  In  the  AEGIS  system,  the  boards  are  strapped 
to  ensure  that  no  process  running  on  another  board 
accidentally  contaminates  the  onboard  memory  of  another 
board . 

The  8086  was  one  of  the  first  commercially  available  16- 
bit  microprocessors.  Figure  3.3  shows  the  internal  structure 
of  the  8086.  The  processor  is  divided  into  an  execution 
unit,  EU,  ar.d  a  bus  interface  unit,  EIU.  The  EU  implements 
a  standard  single-bus,  accumulator  based  arhitecture  and  the 
BIU  manages  all  bus  communications  to  the  outside  world.  The 
data  and  addresses  are  multi-plexed  over  the  same  16  pins  of 
the  40  pin  chip.  The  BIU  also  implements  an  instruction 
pipeline  in  order  to  speed  up  the  execution  in  the  8086.  Up 
to  six  pre-fetched  instructions  are  queued  for  execution. 
General  use  registers,  the  AX,  BX,  CX,  and  DX  registers,  are 
16  bits  wide  and  are  either  8  or  16  bit  addressable.  There 


f lgure  3.3 


8086  Architecture 


are  also  four  word  addressable  registers  for  indicies  and 


pointers,  the  CS(code  segment),  the  DS(data  segment),  the 
SS(stack  segment),  and  the  ES(extra  segment).  These  segment 
registers  serve  as  base  addresses  for  addressing  64K  byte 
segments  within  the  20  bit,  one  megabyte  address  space  of 
the  8086.  In  order  to  effectively  address  one  megabyte,  the 
base  address,  only  16  bits,  is  left  shifted  by  four  bits  so 
that  when  added  to  the  16  bit  offset,  the  full  one  megabyte 
address  space  is  available.  These  segment  registers  are 
programmable  so  that  any  portion  of  the  one  megabyte  address 
space  is  available.  This  enables  the  addressing  of  memory 
space  which  lies  outside  the  64E  of  86/12  SBC  onboard  RAM. 
This  is  crucial  for  the  ability  to  address  the  memory 
expansion  boards  and  other  offboard  components  as  part  of  a 
process  running  cn  the  86/12  SBC. 

2.  Memory  Configuration  on  the  MULTIBUS  System 

The  AEGIS  project  makes  use  of  a  multi  user  system 
to  run  a  multiprocessing  operating  system,  MCOP.TEX,  which 
is  appended  to  the  CPM-S6  operating  system  that  is  resident 
on  each  86/12  SBC.  MCORTEX  is  loaded  from  disk  directly  to 
onboard  memory.  CPM-86  has  a  master  and  a  slave  version. 
The  master  version  is  loaded  from  disk  to  the  MULTIBUS 
master  86/12  SBC.  The  slave  version  is  loaded  onto  a  memory 
expansion  board  called  common  memory?  copies  of  this  are 
then  loaded  into  slave  95/12  SBC's  as  needed.  This  common 


memory  belongs  to  all  boards  and  processes  and  is  the  area 
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where  MCOF.TEZ  places  various  process  synchronization  data. 
The  other  memory  expansion  board,  call  it  the  extended 
T?A( transient  program  area),  is  available  to  any  36/12  SEC. 
For  the  purposes  of  this  thesis,  this  extended  TPA  was  used 
by  the  PL/I  programs  as  a  portion  of  the  data  segment  from 
and  to  which  the  Direct  Memory  Access  operations  for  the 
Ethernet  Control  3oard  were  conducted.  Figure  3.4  depicts 
in  a  linear  manner  the  memory  utilization  in  the  AEGIS 
multi-user  system. 

3.  I_nter Ian  N 130 12  Ethernet  Controller  3oard 
a.  General 

The  Ethernet  controller  Board  is  a  MULTIBUS 
Ethernet  communications  controller  that  together  with  a 
transceiver  implements  layers  one  and  two  of  the  ISO  network 
layer.  It  implements  fully  a  protocol  that  complies  with 
the  Xerox/Intel/Digital  Ethernet  specification,  version  1.0. 

The  board  performs  data  link  layer  functions  by 
formatting  user  data  into  frames  and  performing  the  CSMA/CD 
sensing.  It  automatically  provides  the  cyclic  redundancy 
code  generation  (CRC  code).  The  board,  when  listening  to 
the  network,  recognizes  and  accepts  frames  which  are 
addressed  to  the  board's  physical  address,  one  of  its  multi¬ 
cast  addresses,  or  any  broadcast  frame. 


The  controller  board  performs  the  physical  laye 
functions  by  transmitting/receiving  bit  streams  at  1C 
megabytes  per  second.  It  also  contains  a  16K  receive  buffer 
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so  that  the  host  computer  car  read  the  incoming  frames  or 
packets  at  its  own  convenience.  3y  buffering,  it  also 
shields  the  MULTIBUS  from  the  unpredictable  arrival  time  of 
frames.  The  NI3010  board  has  the  DMA  controller  that  moves 
packets  to/from  host  memory.  The  board  has  control  of  the 
MULTIBUS  during  this  transfer.  Should  another  board  take 
over  the  MULTIBUS  between  data  transfers,  the  NI3010  board 
will  resume  its  DMA  transfer  from  the  point  where  it 
surrendered  the  bus.  The  board  also  maintains  a  small  buffer 
2K  in  length  for  a  storage  of  data  to  be  transmitted.  In 
the  programs  included  herein,  the  NI3012  performs  DMA 
transfers  to/from  the  extended  T?A  memory  board.  The  MI3010 
board  also  performs  extensive  self-diagnostics  and  can  keep 
statistics  on  the  network  traffic  and  errors, 
b.  Frame  transmission 

The  host  computer  sets  up  in  contiguous  memory 
a  transmit  data  area  in  the  extended  T?A.  When  instructed 
by  the  host,  the  NI3010  board  commences  a  DMA  transfer  of 
this  data  into  its  transmit  buffer.  The  board  does  not 
attempt  transmission  onto  the  network  until  specifically 
told  to  do  so  by  the  host.  Once  instructed  to  do  so,  it 
inserts  the  source  address  of  the  board,  computes  and 
appends  the  CRC,  and  transmits  the  packet.  Should  a 
collision  occur  that  prevents  transmission,  the  board  will 
automatically  attempt  to  retransmit  up  to  16  times.  Figure 
3.5  shows  the  format  of  the  transmit  data  area. 
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VAX.  Since  the  login  process  itself  handles  many  users, 
many  user  could  log  in  over  the  Ethernet  to  the  remote  login 
port.  This  car.  he  demonstrated  by  using  the  Sun  Workstation 
to  log  into  the  VAX  system,  then,  using  that  connection,  to 
remotley  log  back  into  the  Sun,  in  turn  using  this  new 
connection  to  remotely  log  into  the  VAX  again,  and  so  on. 
Since  connections  must  be  established  between  unreliable 
hosts  over  unreliable  networks,  a  handshake  mechanism  with  a 
clock-based  sequence  number  intializat  ion  is  used  to  prevent 
erroneous  initialization  of  connections. 

2.  TCP  Specification 

TCP  segments  (header  and  data)  are  sent  as  part  of 
an  IP  datagram?  the  TCP  header  immediately  follows  the  IP 
header.  Figure  4.2  shows  the  format  for  the  TCP  header.  An 
explanation  of  the  fields  now  follows. 

The  source  port  and  destination  port  fieleds  are  used  by 
TCP  so  that  it  may  uniquely  identify  separate  streams  of 
data.  This  address,  along  with  the  address  fields  from  the 
IP  header  form  the  address  of  the  data  stream  that  uniquely 
identifies  it  throughout  the  network.  The  port  address  for 
the  UNIX  login  port  is  02  01  hexadecimal  (513  decimal);  a 
listing  of  this  port  address  and  all  network  services  port 
addresses  can  be  found  in  the  UNIX  file  "/etc/service.s" . 
UNIX  evaluates  all  source  norts  of  inbound  packets  to  see  if 
they  are  between  0  to  03  ff  hexadecimal.  Thus  in  the 
initial  login  request  from  the  Sun  Workstation,  the  source 
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reception  from  the  receiving  TCP.  If  not  acknowledged,  the 
segment  is  retransmitted  after  a  certain  time  interval. 
These  sequence  numbers  also  allow  the  receiving  host  to 
order  incoming  packets  so  that  they  are  provided  to  the  next 
higher  layer  in  the  proper  order.  Damaged  packets  are 
handled  by  adding  a  checksum  for  the  TCP  segment;  damaged 
packets  are  not  processed.  TCP  is  extremely  robust.  It 
provides  recovery  from  any  communications  errors,  providing 
the  TCP  is  itself  functioning. 

TCP  handles  the  problem  of  a  fast  sender  swamping  a  slow 
receiver,  flow  control,  by  use  of  the  window  field.  The 
window  on  an  incoming  segment  indicates  an  allowed  number  of 
bytes  that  the  receiver  may  transmit  before  receiving 
further  permission.  The  window  governs  not  how  many  packets 
are  sent  per  unit  of  time,  but  how  much  data  can  be  sent  at 
any  given  time. 

TCP  allows  for  many  processes  within  a  single  host  to  be 
communicating  with  the  same  remote  host  simultaneously  by 
providing  a  set  of  addresses  within  each  host  called  ports. 
This  port  address,  when  concatenated  with  a  network  and  host 
address  form  what  the  ARPANET  terms  a  socket.  A  pair  of 
sockets,  one  in  each  host,  uniauely  identifies  what  is 
termed  a  connection.  A  connection  is  the  process  to  process 
service  provided  by  TCP.  In  the  remote  login  process,  each 
successful  login  to  the  remote  host  would  form  a  separate 
connection  from  the  user  to  the  remote  login  pert  cf  the 


Figure  2.2  shows  the  position  of  TC?  in  the  ARPANIT 
network  layers.  TCP  would  he  called  upon  by  higher  level 
protocols  to  provide  service  for  then?  and  TC?  would  in  turn 
call  upon  Internet  for  services.  Whatever  data  or  control 
bytes  come  to  it  from  a  higher  layer  would  be  added  to  the 
TCP  header  as  data  and  passed  to  the  IP  layer.  The  TCP 
header  and  its  data,  if  any,  is  called  a  segment,  and  it 
forms  the  data  portion  of  an  I?  datagram  in  the  remote  login 
process.  The  destination  host  must  also  contain  a  protocol 
that  recoginizes  and  evaluates  the  information  contained  in 
the  TCP  segment. 

The  TCP  performs  its  services  to  higher  protocols  by 
providing  mechanisms  that  ensure  data  transfer,  reliability, 
flow  control,  multiplexing,  and  connections.  TCP  allows  a 
continuous  flow  of  data  to/from  each  host.  In  general,  a  TCP 
would  block  and  forward  data  at  its  own  convenience,  but 
there  are  certain  times  when  a  user  must  know  that  the  data 
that  has  been  sent  to  the  TC?  has  teen  transmitted.  This 
user  determined  transmission  of  data  is  called  a  "push”. 
For  instance,  in  the  remote  login/terminal  process,  the  user 
forces  or  "pushes"  the  transmission  of  his  UNIX  command  by 
the  use  of  the  carriage  return  key. 

TCP  can  recover  from  data  that  is  damaged,  lost, 
duplicated,  or  delivered  out  of  order.  This  is  achieved  by 
assigning  a  seauence  number  to  each  byte  of  data 
transmitted,  and  requiring  positive  acknowledgement  cf 


The  source  address  and  destination  address  fields  are 


grouped  into  three  classes,  class  a,  h,  or  c.  The  class 
that  was  obsserved  in  the  remote  login  process  was  the  class 
c  address.  The  class  is  not  a  function  of  the  remote  login 
process*  it  is  the  address  of  the  Naval  Pos trgradua te  School 
on  the  ARPANET.  The  class  c  address  has  three  bytes  of 
network  address  and  one  byte  for  the  local  address.  The 
network  address  of  the  VAX  is  c0  09  c8  03  hexadecimal,  with 
the  03  indicating  its  local  address.  The  Sun  Workstation 
address  is  c0  09  c8  01  hexadecimal.  The  list  of  all  valid 
hosts  to  which  a  particular  UNIX  implementation  can  talk  can 
be  found  in  the  UNIX  file  '/etc/hosts" *  the  addresses  appear 
in  decimal  form,  not  hexadecimal. 

C.  TRANSMISSION  CONTROL  PROTOCOL 
1 .  Background 

The  Transmission  Control  Protcol  (TCP)  was  designed 
to  be  used  as  a  highly  reliable  host  to  host  protocol 
in  packet-switched  networks  and  in  interconnected  systems  of 
such  networks.  It  provides  for  reliable  inter-process 
communication  between  pairs  of  processes  in  host  computers. 
The  protocol  makes  few  assumptions  concerning  the 
reliability  of  the  protocols  which  belong  to  lower  level 
layers.  It  is  designed  to  operate  above  a  wide  spectrum  of 
networks  be  they  hardwired,  packet  switched,  or  circuit 
switched . 
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original  datagram  this  fragment  belongs  and  thus  was 
observed  to  always  be  00  hexadecimal  in  the  remote  login 
process . 

The  time  to  live  field  indicates  the  maximum  time  the 
datagram  is  allowed  to  remain  in  the  Internet  system.  Its 
purpose  is  to  cause  undeliverable  datagrams  to  be  discarded 
and  to  bound  the  maximum  datagram  lifetime.  As  with 
fragmentation,  this  field  is  necessary  if  the  packet  must  be 
sent  over  a  long  haul  network.  The  observed  value  was 
always  07  hexadecimal.  When  remotely  loging  into  a  host  on 
the  same  Ethernet,  this  field  must  contain  a  value  of  at 
least  01  hexadecimal  because  the  IP  specifies  that  packets 
with  this  field  reading  00  hexadecimal  are  to  be  destroyed. 

The  protocol  field  always  reads  06  hexadecimal  which 
indicates  that  the  next  higher  protocol  used  in  the  data 
portion  of  the  datagram  Is  TCP.  The  header  checksum  is  a 
checksum  for  the  IP  header  only.  It  provides  for  high 
reliability  in  the  communications.  In  the  remote  login 
process  since  TCP  and  its  data  form  the  data  portion  of  IP, 
and  this  is  all  covered  by  the  TCP  checksum,  the  entire 
communication  is  covered  by  a  checksum.  The  official 
wording  of  the  checksum  algorithm  is  "....  the  16  bit  one's 
complement  of  the  one's  complement  sum  of  all  16  bit  words 
in  the  header.  For  purposes  of  computing  the  checksum,  the 
value  of  the  checksum  field  is  zero. ’[Ref.  3]  See  Appendix 
F  of  this  thesis  for  further  elaboration  on  the  checksum. 
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datagram).  The  remote  login  process  uses  only  00  in  this 


field  which  indicates  normal  delay,  reliability,  and 
throughput  and  routine  precedence  (as  opposed  to  priority, 
immediate,  flash,  etc.).  The  total  length  field  is  the 
total  byte  count  of  the  datagram,  header  and  data.  The  two 
byte  field  allows  a  length  of  65,535  bytes,  but  this  is 
impractical  for  most  hosts  and  networks.  All  hosts  must  be 
able  to  receive  datagrams  of  at  least  576  bytes. 

Fragmentation  is  not  really  an  issue  wnen  remotely 
logging  in  over  an  Ethernet  to  a  host  which  is  attached  to 
the  same  Ethernet.  The  length  of  the  data  field  in  the 
Ethernet  packet,  up  to  1500  bytes,  is  quite  adequate  to 
accomodate  the  protocols  and  data  that  are  used  in  the 
remote  login/terminal  process.  Fragmentation  does  become  an 
issue  when  the  remote  login  packet  must  cross  long  haul 
networks.  The  next  three  fields  deal  with  fragmentation. 
The  observed  packets  always  had  the  identification  bytes  set 
to  some  host  determined  unique  number  associated  with  a 
particular  source-destination  pair  and  protocol  for  the  tine 
the  datagram  could  be  alive  in  the  network.  That  value  was 
incremented  by  01  hexadecimal  with  each  packet  sent  by  a 
particular  host.  The  flags  field  was  always  00  hexadecimal 
indicating  each  packet  may  be  fragmented  and  that  this 
particular  packet  was  the  last  fragment  (which  matches  with 
the  identification  field  increasing  by  01  hexadecimal  with 
each  packet).  The  fragment  offset  indicates  where  in  the 
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services  reauired  by  I?.  In  the  remote  login  process,  the 
TCP  segment (header  and  possibly  data)  is  the  data  portion  of 
the  IP  datagram.  IP  would  then  call  on  an  Ethernet  device 
driver  to  transmit  the  I?  datagram.  At  the  receiving  host, 
there  must  be  an  IP  protocol  layer  that  properly  interprets 
the  header  information  for  its  next  higher  layer. 

When  a  user  wants  to  send  data  to  a  remote  station  on  a 
long  haul  network,  he  provides  the  application  layer  with 
the  name  of  the  desired  destination.  It  is  the  job  of 
layers  above  IP  to  map  or  change  that  name  into  a  network 
address.  IP  needs  to  know  the  "where"  of  the  destination 
rather  than  the  "who".  IP  depends  upon  lower  level  modules 
to  provide  the  route  for  its  datagram  to  follow  across  the 
network. 

2 .  IP  Specification 

Figure  4.1  shows  the  I?  header  format.  A 
discussion  of  the  fields  follows.  The  version  field  is  four 
bits  long  and  shows  the  version  number  used  for  the 
information  contained  in  this  header.  The  current  versior, 
of  IP  header  is  4.  The  IHL  field,  4  bits,  is  the  length  of 
the  Internet  header  in  32  bit  words  and  is  used  to  determine 
where  the  IP  data  bytes  begin  in  the  datagram.  The  minimum 
length  of  the  IP  header  is  5.  In  the  remote  login  process, 
the  IffL  is  always  5  (20  bytes  of  header).  The  type  of 
service  tells  how  the  datagram  is  to  be  treated  during  its 
trip  throughout  the  network  (how  important  is  this 


sufficiently  general  sc  that  the  remote  login  could  take 
place  from  the  Sun,  over  the  Ethernet  to  the  7AX,  and  then 
over  the  ARPANET  to  another  node  running  4.2  3SL  UNIX.  A 
much  less  complex  method  could  have  been  implemented,  but  it 
would  not  have  complied  with  ARPANET  specifications. 
Besides,  since  there  is  a  large  bandwidth  available  on  the 
Ethernet,  these  extra  bytes  take  up  little  ’’space'’. 


B.  INTERNET  PROTOCOL 

1 .  Background. 

The  Internet  Protocol  (IP)  was  developed  for  use  in 
packet  switched,  interconnected  networks.  The  fundamental 
purpose  of  IP  is  to  transfer  data  from  one  host  to  another 
over  a  long  haul  network  and  to  allow  long  blocks  of  data  to 
be  broken  up  into  smaller  pieces  (fragmentation)  should  a 
particular  link  in  the  network  not  be  able  to  handle  that 
sized  block  of  data.  The  block  of  data  transferred  by  I?  is 
referred  to  as  a  datagram.  The  IP  datagram  consists  of  two 
elements,  a  header  and  the  actual  data.  The  scope  of  this 
protocol  is  limited;  it  does  not  provide  for  end  to  end 
reliability,  flow  control,  sequencing,  or  other  host  to  host 
protocols.  These  later  functions  are  the  objects  of  the  next 
higher  protocol,  TCP. 

Figure  2.2  shows  the  relation  of  IP  to  the  other 
ARPANET  protocols.  The  layering  indicates  that  the  IP  would 
be  called  upon  to  provide  services  for  the  next  higher 
protocol,  TCP,  and  to  call  upon  the  network  interface  for 


only  three  devices  connected  to  it  at  the  tire,  it  was 
possible  to  eliminate  all  traffic  on  th°  cable  except  these 
packets  that  were  directly  involved  with  this  remote 
login/terminal  process. 

Examination  of  the  packets  revealed  that  several 
protocols  were  present.  The  most  obvious  protocol  was  the 
Ethernet  protocol.  The  only  item  of  interest  here  as  far  as 
the  remote  login  was  the  Ethernet  header  type  fields.  As 
mentioned  in  Chapter  II,  this  field  is  undefined  in  the 
Ethernet  specifications  and  is  available  to  the  user  for 
whatever  use  he  deems  appropriate.  In  this  case,  the  low 
order  byte  of  the  type  field  was  always  S  hexadecimal  and 
the  high  order  byte  was  0.  The  reason  for  this  is  not  known 
to  the  author. 

There  were  two  ARPANET  protocols  present,  the  Internet 
and  TCP  protocols.  There  were  also  UNIX  login,  terminal, 
and  trailer  protocols.  The  login  and  terminal  protocols  are 
very  similar  to  those  used  during  a  normal  login  session 
when  a  terminal  is  hardwired  into  the  VAX  UNIX.  The 
conversation  over  the  Ethernet  can  be  viewed  as  protocols 
wrapped  in  protocols.  The  Ethernet  protocols  are  the 
outermost  layer,  then  Internet  and  TCP,  then  the  UNIX 
protocols . 

At  first  glance  it  appears  that  there  is  a  lot  of  excess 
baggaee  used  to  merely  become  a  terminal  over  the  Ethernet. 
However,  the  implementation  used  by  4.2  3SD  UNIX  is 


IV.  RZMOTT  LOGIN  PROTOCOLS 


A.  UNIX  REMOTE  LOGIN 

1 •  What  is  a  Remo te  Login 

When  a  user  desires  to  remotely  log  into  the  VAX 
from  the  Sun  Worksation,  he  executes  the  UNIX  command 
P.LOGIN .  The  Sun  then  sends/receives  packets  over  the 
Ethernet  to/from  the  VAX  login  port.  The  terminal  attached 
to  the  Sun  appears  to  the  user  as  if  it  were  hardwired 
directly  into  the  VAX.  All  of  the  networking 

implementations  are  transparent  to  the  user.  All  of  the 
normal  login  messages  and  terminal  queries  appear,  as  does 
the  same  command  line  prompt  used  on  the  VAX  UNIX.  All 
special  control  characters,  such  as  "kill",  ’delete’,  etc., 
are  exactly  as  those  used  on  the  VAX.  Investigating  the 
viability  of  duplicating  this  process  on  the  AEGIS  multiuser 
system  is  the  goal  of  this  thesis. 

2. 

The  first  step  taken  in  investigating  the  UNIX 
remote  login  processs  was  to  produce  a  program  for  the  AEGIS 
project's  multiuser  system  that  passively  listened  in  on 
the  Ethernet  and  captured  the  conversation  between  the  VAX 
and  the  Sun  when  remotely  logging  in  and  conducting  a 
terminal  session.  The  program,  LISTEN,  captured  all  traffic 
on  the  Ethernet  and  printed  it  into  a  file  in  either 
hexadecimal  or  binary  format.  Since  the  Ethernet  cable  had 
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c.  Frame  receptions 

When  the  NI3010  receives  a  packet  that  is 
destined  for  its  host,  it  informs  the  host  via  a  hardware 
interrupt.  When  the  host  decides  it  is  ready  for  the  packet, 
it  signals  the  board  which  then  prefixes  frame  status  and 
frame  length  information  to  the  received  frame,  and  then 
performs  a  DMA  transfer  of  the  packet  into  a  host  determined 
area  of  memory.  In  the  AEGIS  project,  it  is  transferred  to 
the  extended  TPA  portion  of  memory.  Figure  3.6  shows  the 
format  of  a  packet  that  has  been  transferred  to  the  receive 
data  area. 
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port  is  2 3  ff  hexadecimal  and  the  destination  port  is  02  21 
hexadecimal.  Should  multiple  users  desire  to  log  into  the 
VAX  from  the  Sun  Workstation,  each  would  use  a  destination 
port  address  of  02  01  hexadecimal,  but  each  would  use  a 
separate  source  address  between  0  and  03  ff  hexadecimal. 
This  would  uniauely  identify  each  TCP  connection  and  hence 
each  separate  login. 

The  sequence  number  field  is  a  32  bit  number  that  refers 
to  the  first  data  byte  in  the  data  portion  of  that 
particular  TCP  segment.  If  there  is  no  data  present  in  the 
TCP  segment,  such  as  in  the  case  of  acknowledgement  only 
packets,  then  the  sequence  number  refers  to  the  data  byte 
that  will  next  be  sent  by  that  socket.  Since  every  byte  of 
data  is  assigned  a  sequence  number,  the  segment  sequence 
number  is  the  lowest  unused  number  in  the  32  bit  sequence 
number  space.  The  acknowledgement  number  field  in  a  TCP 
segment  is  the  sequence  number  of  the  next  expected  data 
byte  of  transmission  in  the  reverse  direction.  Since  every 
byte  of  data  has  a  sequence  number,  each  of  them  can  be 
acknowledged.  The  simplest  form  of  the  acknowledgement 
procedure  is  to  make  it  cumulative  so  that  an 
acknowledgement  number,  call  it  X,  indicates  that  all 
sequence  numbers  up  to,  but  not  including  X,  have  beer, 
received.  The  initial  seauence  number  is  chosen  based  on  a 
clock  based  algorithm.  This  enables  TCP  to  detect  duplicate 
packets  from  a  previous  instance  of  the  connection.  It  is 


important  to  note  that  a  pure  acknowledgement  packet  dees 
not  contain  data  and  hence  does  not  occupy  sequence  number 
space . 

The  data  offset  field  is  the  number  of  32  bit  words  in 
the  TCP  header.  The  reserved  field  is  reserved  for  future 
use  and  is  filled  with  0's.  Each  bit  in  the  control  field 
informs  the  TCP  of  a  particular  kind  of  event;  each  event 
requires  different  processing  depending  upon  in  which  state 
the  TCP  is.  More  on  TCP  states  will  appear  later  in  this 
thesis.  The  control  bits  indicate  that  the  urgent  or 
acknowledgement  fields  are  significant,  that  data  is  to  be 
pushed,  to  reset  the  connection,  synchronize  seauence 
numbers,  and  that  no  more  data  is  to  be  sent  over  this 
particular  connection. 

The  window  field  is  the  number  of  bytes  of  data  that  the 
sender  of  the  segment  is  willing  to  accept  from  the  other 
end  of  the  connection.  This  is  based  on  the  size  of  the 
buffers  available  in  a  particular  implementation  and  how 
much  data  is  in  each  of  the  buffers  at  any  given  time.  The 
observed  values  in  the  remote  login  were  predominantly  08  PC 
hexadecimal,  2048  decimal.  The  window  is  the  mehanism  by 
which  a  fast  sender  does  not  swamp  a  slow  receiver.  If  a 
sender  sends  data  that  is  more  than  can  be  received,  that 
data  would  be  discarded,  thus  adding  to  the  network  traffic 


by  necessitating  retransmission.  By  examining  the  sequence 
number  and  window  size  on  an  incoming  packet,  a  TCP  can 
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determine  whether  or  not  tne  number  of  bytes  that  it  has  to 
send  can  he  received  at  the  other  Pnd. 

The  checksum  field  uses  the  same  algorithm  for 
computation  as  the  I?  checksum;  it  covers  a  psuedo  header, 
the  TC?  header,  and  the  data  portion  of  the  segment.  The 
pseudo  header  is  a  12  byte  header  which  contains  the  source 
and  destination  addresses  from  the  I?  header,  a  zero  byte, 
the  protocol  number'06,  which  indicates  TCP),  and  the  TC? 
length.  The  length  is  the  length  of  the  TCP  header  and 
data?  it  does  not  count  the  12  bytes  of  pseudo  header. 
Should  the  length  be  an  odd  number,  then  a  zero  byte  is 
appended  as  padding  in  order  to  form  the  full  16  bit  words 
for  the  checksum  algorithm.  Figure  4.3  shows  the  format  of 
the  pseudo  header. 
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Figure  4.3  Pseudo  Header  Format 

The  urgent  pointer  field  allows  the  sender  to  notify  the 
receiver  that  some  urgent  data  follows.  The  pointer  is  an 
offset  value  from  the  sequence  number  of  the  packet  with  the 
urgent  control  bit  set;  it  points  to  the  last  byte  of  urgent 
data.  In  the  remote  login  process,  the  options  fields  i  r. 
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the  TC?  healer  are  utilized  only  during  the  establishment  of 
a  TCP  connection.  The  option  observed  specified  the  maximum 
segment  size  as  being  1224  bytes.  The  padding  field  is  used 
only  to  ensure  that  the  TC?  header  contains  full  32  bit 
words.  The  padding  is  the  zero  byte. 

3.  TCP  States 

A  connection  moves  through  a  progression  of  states 
during  its  existence.  Figure  4.4  is  a  finite  state  model  of 
the  TCP  connection  states.  It  should  not  be  considered  as  a 
complete  state  diagram?  it  depicts  only  a  few  of  the  events 
that  can  cause  a  state  change.  The  TC?  may  change  states 
based  on  the  events  OPEN,  CLOSE,  SEND,  RECEIVE ,  and  ABOP.T 
and  the  control  flags  that  are  set  in  incoming  segments. 
The  listen  state  represents  waiting  for  a  connection  request 
from  any  remote  TC?  and  pert.  Syn-sert  represents  waiting 
for  a  matching  connection  request  in  response  to  the 
original  connection  request.  The  syn-receiv°d  represents 
the  waiting  for  an  acknowledgement  of  the  syr.  which  was  sent 
in  response  to  an  incoming  syn.  The  established  state 
represents  an  open  connection  over  which  data  car.  now  be 
sent  in  either  direction.  The  fin-wait-1  state  represents 
waiting  for  a  termination  reauest  or  the  acknowledgement  on 
one  that  was  sent.  The  fin-wait-2  state  represents  only  the 
waiting  for  a  termination  reauest.  The  close-wait  state 
represents  waiting  for  a  termination  request  from  the  local 
user.  The  closing  state  represents  the  waiting  for  c 


connection  termination  reouest  acknowledgement  for  the 
remote  TCP.  The  last-ack  state  represens  the  wait  for  an 
acknowledgement  of  the  connection  termination  request 
previously  sent  to  the  remote  TCP.  The  time-wait  state 
represents  waiting  for  enough  time  to  pass  to  make  sure 
that  the  remote  TCP  has  received  acknowledgement  of  its 
connection  termination  reouest. 

When  a  particular  event  takes  place,  the  TCP  response  to 
that  event  depends  upon  the  state  of  the  TCP?  the  same  event 
can  cause  different  TCP  reactions.  The  response  to  inbound 
packets  is  very  complex;  the  algorithms  covering  the  proper 
responses  are  found  in  Reference  3.  The  states  of  the  TCP 
could  be  lumped  together  into  three  primary  states;  the 
first  state  has  to  do  with  getting  a  connection  set  up  from 
one  host/port  to  another,  the  second  concerns  the  handling 
of  inbound/outbound  packets  once  established,  and  the  third 
has  to  do  with  terminating  the  connection.  The  UMIX  command 
NETSTAT  will  show,  among  other  things,  the  state  of  each  TCP 
connection  . 

4.  Connection  Establishment 

For  a  connection  to  move  to  the  established  state, 
the  two  TCP's  must  synchronize  on  each  other's  initial 
seauence  numbers.  Since  the  initial  sequence  number  from 
each  socket  is  unique  (they  are  clock  generated,  but  not 
from  a  network  wide  clock),  this  synchronization  is 
necessary  so  that  the  acknowledgement  mechanism  can  function 


properly.  This  synchronization  is  signaled  by  the  s yn  's 
control  bit  in  the  TCP  header  being  set.  The 
synchronization  requires  each  TCP  to  send  its  own  uniquely 
determined  seauence  number  and  to  receive  acknowledgement 
that  it  has  been  received  by  the  other  end  of  the  proposed 
connection.  An  example  of  the  connection  establishment  is 
shown  in  Figure  4.5.  The  initial  TCP  from  3  can  contain 
both  the  acknowledgement  and  the  initial  sequence  numcer 
thus  resulting  in  a  total  of  three  packets.  This  is  where 
the  exchange  get  its  name  of  the  "three  way  handshake'. 

The  demonstration  program  in  this  thesis  dees  follow  the 
above  synchronization  of  sequence  numbers  and  produces  a 
connection  that  moves  into  the  "established"  state.  It  does 
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syn,  my  sequence  number  is  X 

b. 
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3 

ack,  your  sequence  is  X 

syn,  my  sequence  number  is  7 

c . 

A 

______  s 

3 

ack,  your  seauence  number  is  Y 

Figur  e 

4 . 5 

TCP  Connection  Establishment 

not  handle,  in  a  TCP  sense,  the  production  of  transmission 
packets  nor  the  processing  of  inbound  packets  in  the 
established  state  nor  for  connection  termination.  The 
algorithms  for  all  event  processing  are  contained  in 


Reference  3. 


D.  UNIX  PROTOCOLS 


1 •  2§CKgrcund 

All  of  the  protocols  discussed  thus  far  have  been 
very  general  and  can  be  applied  to  many  networking 
situations.  The  Ethernet,  IP,  and  TCP  protocols  do  not 
pertain  directly  to  the  remote  login/terminal  process  per 
se.  They  are  just  as  valid  for  sending  mail,  transferring 
files,  etc.  as  they  are  for  the  remote  1 cgin/terminal .  The 
UNIX  protocols  that  will  now  be  discussed  are  specific  to 
the  remote  login/terminal  process. 

2.  UNIX  Remote  Login  Protocol 

A  description  of  the  remote  login  protocols  can  be 
found  in  the  System  Maintenance  section  of  Reference  4.  The 
servers  for  the  protocols  are  PLOGIND(eC)  and  RSED(6C). 
When  the  UNIX  receives  a  request  for  a  remote  login  over  a 
network,  it  is  RLOGIND  that  is  listening  at  the  rlogin  port 
for  such  requests  (listen,  in  the  sense  of  a  TCP  state 
diagram).  Upon  receiving  a  request,  RLOGIND  along  with 
PSHD  checks  to  see  if  the  requestor's  source  port  is  witnin 
the  range  1-1023.  They  read  characters  from  the  socket  un 
to  the  null  byte  (00  hexadecimal)  and  interpret  them  as 
ASCII  characters.  They  check  to  ensure  that  the  requestor's 
address  is  one  contained  in  their  host's  name  data  base.  A 
cull  terminated  user  name  of  at  most  16  characters  is  next 
read  and  is  considered  to  be  the  user  name  for  the  host 
machine?  a  second  null  terminated  user  name  is  read  and  is 
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cons ide red  the  user  name  on  the  reauestor's  machine.  Next, 
a  null  terminated  command  to  the  UNIX  command  shell  is 
retrieved.  The  user  name  is  then  checked  against  the  list 
of  authorized  users.  When  all  the  above  steps  are 
successful,  the  null  byte  is  returned  over  the  connection  to 
the  requestor.  The  connection  is  now  passed  on  to  the 
regular  login  process  for  the  verification  of  the  password. 

The  above  steps  are  those  described  in  the  UNIX 
operating  system  manuals.  Observations  of  the  conversation 
over  the  Ethernet  during  the  remote  login  process  reveal  the 
following.  A  three  way  handshake,  according  to  TCP, 
etablishes  a  connection  from  the  Sun  Workstation  to  the 
remote  login  port  of  the  VAX  system.  (A  UNIX  NETSTAT 
command  issued  after  only  the  three  way  handshake  packets 
have  been  transmitted  will  show  that  the  logic  port  of  the 
VAX  has  a  network  connection  to  the  foreign  address,  Sunl. 
The  state  of  the  connection  will  read  'established'.)  In 
the  next  packet,  the  Sun  Workstation  then  pushes  the  null 
byte?  then  a  new  packet  which  has  the  user  name  as  data, 
then  the  next  packet  which  also  has  the  user  name  as  data, 
then  the  terminal  type/baud  rate  appears  as  data  to  the  VAX. 
The  Vax  will  then  send  "Password”  to  the  Sun  Workstation  as 
data  to  be  displayed  on  the  Sun  terminal.  This  is  the  first 
displayable  data  that  is  passed  to  the  Sun  Workstation.  The 
Sun  will  now  be  using  the  protocol  discussed  below. 


3.  UNIX  Terminal  Protocol 

Terminals  connected  to  a  VAX  11/780  running  4.2  BSD 
UNIX  are  full  duplex,  character  at  a  time  connections  that 
normally  terminate  at  a  communications  interface  processor. 
When  typing  at  the  terminal,  each  key  stroke  is  sent 
separately  to  the  UNIX?  it  is  returned  or  "echoed"  to  the 
terminal  so  that  it  can  he  displayed  on  the  screen.  The  echo 
is  displayed,  not  the  key  when  struck.  It  is  this  echo 
feature  that  enables  the  user  to  type  in  a  password  without 
it  appearing  on  the  screen.  The  operating  system  knows  when 
the  user  is  sending  a  password,  so  it  does  not  return  or 
echo  the  keystroke  to  the  terminal.  When  using  the  remote 
terminal  feature  of  the  UNIX,  the  remote  terminal  is  treated 
in  the  same  manner  as  described  above.  The  remote  terminal 
process  transmits  each  keystroke  as  a  single  packet;  the 
provider  of  the  service  replies  with  a  single  packet  that 
echoes  the  keystroke  (this  echo  is  then  acknowledged  in  an 
ack  only  segment).  When  the  VAX  system  is  sending  lines  cf 
text  to  be  displayed  on  the  remote  terminal,  it  will  send  at 
most  one  line  of  data  in  each  packet  with  ASCII  carriage 
return  and  line  feed  characters  as  the  line  terminators. 

4.  Protocols 

Section  70  of  Reference  4  contains  information  on 
the  use  of  trailing  protocols.  They  appeared  after  the  data 
bytes  of  the  TCP  when  the  length  of  IP,  TCP,  and  data  was 
less  that  the  minimum  Ethernet  data  length  of  46.  For 


instance,  if  the  remote  login/terminal  .ARPANET  packet  was 
only  43  bytes  long,  there  was  a  6  byte  trailer  added  to  the 
packet  to  make  it  a  total  of  46  bytes  long.  No 
investigation  into  the  contents  of  these  protocols  was 
conducted . 

5.  Summary  of  Remote  Logi n/Termina 1 

Figure  4.6  depicts  the  protocols  that  have  been 
investigated  during  the  course  of  this  thesis.  There  would 
be  other  layers  above  these,  but  they  were  neither 
investigated  nor  programmed  in  the  demonstration  program. 


Figure  4.6  UNIX  Remote  Login  Protocols 
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V.  TEST  0?  VIABILITY 


A.  DEMONSTRATION  PROGRAM 

1.  Goals  of  the  Demonstration  Program 

In  order  to  test  the  viability  of  a  remote  login  to 
the  UNIX  over  an  Ethernet  from  a  CPM  based  process,  a 
demonstration  program  was  devised  that  mimicked  the  remote 
login  conversations  between  the  Sun  Workstation  and  the  VAX 


UNIX  system.  The  demonstration  program  used  the  Sun 
Workstation's  Ethernet,  ARPANET,  and  login  port  addresses. 
The  program  did  not  attempt  a  full  implementation  of  the 
IP/TCP  protocols  nor  of  the  UNIX  remote  login/termi nal 
protocols.  The  goal  of  the  program  was  to: 

a.  establish  a  TCP  connection  between  the  CP.M  based 
process  and  the  login  port  of  the.  VAX  UNIX  machine 
(three  way  handshake)  and 

b.  to  proceed  through  the  UNIX  remote  login  protocols 
far  enough  that  >tthe  VAX  UNIX  transmitted  the 
request  ’Password"  (requestor  has  successfully 
passed  through  the  remote  login  and  has  been  handed 
off  to  the  standard  UNIX  login  process). 

The  successful  accomplishment  of  this  could  be 
determined  through  the  use  of  the  UNIX  command  NETSTAT  and 
the  examination  of  the  packets  that  were  sent  by  the  VAX 
system  in  re  ply  to  the  demonstration  program.  If  the  Sun 
Workstation  is  turned  off  and  then  the  demonstration  progran 
is  run,  executing  the  command  NETSTAT  will  show  that  the  VAX 
UNIX  has  a  TCP  connection  "established"  to  its  login  port 
from  the  remote  host  Su.nl.  Examination  of  the  packets 
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returned  to  the  demonstration  program  by  the  VAX  UNIX  system 
shows  acknowledgement  by  the  VAX  system  of  all  data  received 
and  the  word  "Password"  passed  as  the  data  portion  of  its 
packets.  The  demonstration  program  went  no  further?  the 
user's  password  was  not  sent  to  the  VAX,  no  remote  terminal 
protocols  nor  TCP  connection  termination  protocols  were 
attempted.  Since,  full  protocols  were  not  programmed,  the 
program  assumes  that  a  normal,  trouble  free  remote 
login/terminal  sequence  will  occur.  Thus  there  can  not  be 
any  other  packets  on  the  Ethernet  not  concerned  with  the 
remote  login  process. 

Numerous  observations  of  the  remote  login  were  obtained 
by  the  program  LISTEN.  The  three  way  handshake  was  observed 
as  described  in  the  previous  chapter.  The  demonstration 
program  sent  out  a  reauest  for  a  connection  to  the  VAX  UNIX 
login  port,  waited  for  the  return  "syn,ack"  from  the  VAX, 
then  sent  an  acknowledgement  of  that  packet,  when  forming 
this  acknowledgement  packet,  the  demonstration  program, 
DEMO,  only  processed  the  inbound  packet  for  its  sequence 
number . 

Figure  5.1  illustrates  the  observed  sequence  for  the 
UNIX  remote  login  protocol.  BZMC  sent  out  its  packets 
assuming  this  would  be  the  seauence  of  events!  it  pushed  the 
four  packets,  waited  for  the  ack  and  then  null  byte  from  the 
VAX,  ar.d  then  processed  the  VAX  packet  for  its  sea ue nee 
number  with  which  it  could  form  an  acknowledgement  packet. 
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2.  Demonstration  Program  Results 

The  demonstration  program  was  successful  in  meeting 
its  goals.  A  TCP  connection  was  established  and  the  UNIX 


Sun 

VAX  UNIX 

null  byte 
user  name 

user  name 
sun/9600 

ack 

null  byte 

ack 

Password 

Figure  5.1  UNIX  Remote  Login  Sequence 


remote  logi n  protocols  were  successfully  negotiated  ar.d  the 
request  passed  onto  the  normal  login  process  of  the  V A X 
UNIX;  the  requestor  was  asked  for  his  password. 

3.  Significant  Program  Development  Anomalies 

During  the  development  of  both  the  demonstration 
program  and  the  LISTEN  program,  several  important  anomalies 
developed;  one  concerned  the  network  protocols,  another  the 
the  NI301U  board,  and  lastly  the  asynchronous  interrupts 
while  C ?rd  is  executing  i/o. 

When  DF^IO  is  being  used,  it  initiates  a  TCP  connection 
with  the  VAX  UNIX  system  in  accordance  with  the 
specifications.  However,  it  does  not  terminate  the 
connection  according  to  the  TCP  protocol.  When  DFtdO  is 
finished,  the  connection  is  one  sided;  the  VAX  still  thinks 
that  it  has  a  connection  to  the  Sun.  The  connection 
eventually  times  out  when  the  "AX  fails  to  receive  ary  more 
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2  source_address_e 
2  source_ad.d  ress_f 
2  type_field_a 
2  type~field_b 
2  da ta~ ( 1520  ) 

2  crc_msb 

2  crc_upper_middle_byte 
2  crc_lower_middle_byte 
2  crc_lsb 

size_ptr  pointer, 
size  fixed  bin(15)  based  (size_ptr), 
fill_xtpa (15000  )  char  based (rec_bik_ptr  )  , 
output_type  char(l), 
user_desires  fixed, 
packet  file, 
rec_blk_ptr  pointer, 

number _of_packets  fixed  static  init(3), 
copy_ie_register  bit(3), 
i  fixed  bin  (15), 

reg_value  bi t  (8)  ,  /  ,  w 

border  (80)  char  (1)  static  initial  ((90)  -  ), 


/*  Modules  external  tc  this  module  */ 

.bit  ( 3 )  )  , 
.bit  (8)  ), 

entry, 
entry , 
entry, 


/*  end  module  listing  */ 


^replace 


next_p age 

by  '"1', 

cl  e 

arscreen 

by  '  z  ' ! 

/* 

codes  specific  to  the  Intel  9259a 

Programmable  Interrupt  Controller 

(PIC) 

*/ 

icvl  port  address 

by 

"c0 

'b4, 

/* 

note 

that  */ 

icw2  Dort  address 

by 

'c2 

'b4. 

/* 

icw2 , icw4 , */ 

icw4  port  address 

by 

'c2 

b4  , 

/* 

and 

ocv  */ 

ocw  port_add ress 

by 

'c2 

'b4 , 

/* 

use 

sane  */ 

/* 

port 

addr  */ 
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write_io  port  entry  (bit  j 9 ) 
read_io_port  entry  (bit  ’ 9 ) 
ini t Tali ze_cpu_in ter rupts 
enable_cpu_interrupts 
disable_cpu_interrupts 
write_bar  entry  (pointer); 


b  i  t 

( 9 )  , 

bit 

(3)  , 

b  i  t 

/  \ 

>.  r  i  , 

bit 

(S  )  , 

bit 

S), 

bit 

(8)  , 

bit 

(8)  , 

bit 

(3)  , 

X  >;-! 

bit 

(S)  , 

APPENDIX  C 


LISTING  0?  LISTEN  PROGRAM 


listen:  procedure  options  (main); 

/*!! m  l  !!!!!  !!!  !!!!!!  !!! !!!  I  !  m  !  I  if!!!!!!!!!!!!!!!!!!!!!  ! 

date:  20  november  1984 
John  Donald  Eeeke 

This  program  will  capture  all  packets  that  are  on  the 
Ethe rne t.  It  does  this  by  initializing  the  N 13 010  board  to 
the  promiscuous  mode.  The  packets  are  placed  one  after  the 
other  in  memory  starting  at  8000  hex,  the  first  byte  of  the 
extnded  tpa .  The  contents  of  the  packets  are  output  to  the 
file  PACKET. D.'T  but  not  to  the  terminal.  The  user  selects 
either  hexadecimal  or  binary  output  and  also  the  number  of 
packets  the  program  will  receive  before  termination.  An 
anomally  exits  in  the  NI3010  board.  Always  hard  reset  the 
MULTIBUS  backplane  before  using  this  program.  When  the 
anomally  is  present,  an  extra  byte,  00  hex,  precedes  the 
first  packet  dma  'ed  from  the  board.  This  causes  the  receive 
block  overlay  to  be  off  by  this  one  byte;  therefore,  the 
size  of  the  first  packet  is  not  properly  determined  by  the 
program  . 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*/ 


declare 


receive  data  block  based*! 

re 

c  b  1  k  p  t  r  ) 

2 

f rame_status 

bit 

(3 ) 

* 

2 

null_byte 

bit 

(3) 

9 

2 

f rame_length_lsb 

bit 

(8) 

9 

2 

frame_length_msb 

bit 

(S) 

9 

2 

destination_address_ 

a 

bit 

(£) 

9 

2 

dest inat ion_add res  s~ 

b 

bit 

(3) 

9 

2 

destination_address_ 

c 

bit 

(3) 

9 

2 

dest inat ion_add res  s_ 

d 

bit 

(3) 

9 

2 

destinatlon_address_ 

e 

bi  t 

(3) 

9 

2 

dest inat ion_address_ 

f 

bit 

(3) 

9 

2 

source _address_a 

bit 

(8) 

9 

2 

source_add  re  ss_b 

bit 

(3) 

9 

2 

source_address_c 

bit 

(3) 

9 

2 

source  address  d 

bit 

(5) 

9 

£0 


interrupt_handler : 


;  IP,  CS,  and  flags  are  already  on  stack 
*  save  all  other  registers 

push  ai 
push  bx 
push  cx 
push  dx 
push  si 
push  di 
push  bp 
push  ds 
push  es 

call  hl_interrupt_handler 

;  high  level  source  routine 
?  In  Ethertest  Module  (PL/I) 


?  restore  registers 


pop  es 
pop  ds 
pop  bp 
pop  di 
pop  si 
pop  dx 
pop  cx 
pop  bx 
pop  ax 


ini tmodule  cseg  common 
ora  114h 

int5_offset  rv  1 
int5_segment  rv  1 

cseg 
push  bx 
push  ax 

mov  hx ,  offset  interrupt_handler 

m  o  v  a  x  ,  0 

push  ds 

mov  ds,  ax 

mov  ds  :int5_of f set ,  bx 

mov  bx,  cs 

mov  ds :int5_segment ,  bx 

poo  ds 

pop  ax 

pop  bx 

s  ti 

ret 


erable_cpu_in  terrupts : 

;  Module  Interface  Specification: 

;  Caller:  Ether  test ( ?L/I )  Procedure 

5  Parameters:  NONE 

sti 

ret 


disable _cpu_interrupts: 

;  Module  Interface  Specification: 

*  Caller:  Ether tes t (PL/I )  Procedure 

J  Parameters:  none 


cl 

*e 


e_bar_port 

equ 

3b9h 

h_bar~por  t 

equ 

3bah 

l_bar_por t 

ea  u 

3b  bh 

temp_e_by te 

rb 

1 

temp_es 

rw 

1 

cseg 


This  module  computes  a  24  hit  address  from  a  32  bit 
address  -  actually  it's  a  combination  of  the  2S  registe 
and  the  IP  passed  via  a  parameter  list. 


add  is 


push  bx  ! 

push  ax!  push  cxl  push 

es!  push  dx I  push  si 

mov 

dx,  0£33h  ;  common  memory  segment 

mov 

es ,  dx 

mov 

temp_es,  es 

mov 

dx ,  es 

mov 

si,  [bx] 

mov 

ax,  [si] 

mov 

cl,  12 

shr 

dx ,  cl 

mov 

temp_e_byte,  dl 

mov 

dx,  temp_es 

mov 

cl ,  4 

shl 

dx ,  cl 

add 

ax ,  dx 

jnc 

r.o_add 

inc 

temp_e  byte 

:  out 

l_bar_port,  al 

mov 

al ,  ah 

out 

h_bar_port  ,  al 

mov 

al,  temp_e_byte 

out 

e_bar_port,  al 

pop 

siT  pop  dx !  pop  es  !  pop 

cx!  pop  ax!  pop  bx 

ret 

initial! ze_cpu_interrupt s  : 

;  Module  Interface  Specification: 

;  Caller:  Ethert es t ( PL/I )  Procedure 


t 


Parameters : 


NONE 


push  bx!  push  si!  push  lx!  push  ax 

mov  si,  t b x ] 

mov  al,  [si] 

mov  port_addres s ,  al 

mov  si,  2[bx] 

mov  al,  [si] 

mov  dl,  port_address 

mov  dh,  00h 

out  dx,  al 

pop  ax!  pop  dx !  pop  si!  pop  bx 
ret 


J  #  sfc ## xe SC*####  Sr Sfc Sr:### s*  ##  $  #S(SSjC  *S  ##>)t#sls  SjCSj!  if  sis##  SiSSjtSiCSfc  **C:4tS(t3jCSit 


read_io_por t : 


Parameter  Passion  Specification 

entry 


exit 


parameter  1  <port  address> 

parameter  2  <meaningles s> 


<unchanged> 
<register  value> 


cseg 


push 

bx ! 

push  si!  push  dx!  push  ax 

mov 

si. 

[bx] 

mov 

al, 

[si] 

mov 

port 

_address,  al 

mov 

si  , 

2[bx] 

mov 

dl. 

port  address 

mov 

dh, 

00h~ 

i  n 

al. 

dx 

mov 

[si] 

,  al 

pop 

ret 

ax ! 

pop  dx!  pop  si!  pop  bx! 

j  ipsissjiXcXssisxt^Xtsits^^tXss^^ssisXtsftsisXisjtXtXssitXssisstt^ssisXtsftsfcstts^sjtXcXs^sits^sitXcsitsJsjjts^Xts^sitXt#  Xtj(sX:X!Xtsi« 

wrlte_bar : 

;  Parameter  Passing  Specification 

9 


parameter  1  :the  address  of  the  data  bloc's  to  be 
transmitted  or  received. 


appendix  b 


NI3010  DEVICE  DRIVE?.  ASSEMBLY  LANGUAGE  MODULES 
date:20  November  1984 
author:  David  J  Brewer 

These  3086  Assembly  language  modules  were  developed  by 
Brewer  for  his  thesis.  [Ref.  5]  They  are  linked  into  any 
program  that  needs  to  utilize  an  Interlan  NI3010  Ethernet 
Controller  Board.  They  read/write  to  the  various  ports  of 
the  NI3010,  initialize  the  interrupt  5  for  the  CPU,  ar.d 
enable/disable  the  CPU  interrupts. 


XTERNASY 


extrn  hl_inte rrupt_handl er  :  far 

public  write_io_port 

public  read_io_port 

public  write_bar 

public  initialize_cpu_interrupts 

public  enable_cpu_interrupts 

public  disable_cpu_interrupts 

j  s':  ##  jjt  5*  # #£*:***  j<s  *>je  s*  #  sjt  3** 

write_io_port  : 

;  Parameter  Passing  Specification: 

;  entry  exit 

t 

;  parameter  1  <port  address>  <unchanged> 

* 

•  parameter  2  <value  to  be  outputted>  <unchanged> 


dseg 

port_address  rb  1 


transferred  into/out  of  memory  with  the  most  significant 
byte  first  followed  by  the  least  significant  byte. 
Therefore  a  two  byte  PL/I-S6  variable  cannot  be  overlayed  on 
the  IP  length  bytes.  Similarly,  the  hexadecimal  value  12  34 
is  stored  in  memory  as  34  12.  This  is  important  when 
storing  16  bit  hexadecimal  values  in  bit(16)  variables  such 
as  the  TCP  source  and  destination  port  addresses. 


An  important  point  to  remember  in  network 
implementations  is  that  only  binary  information  is  received 
or  transmitted.  The  interpretation  of  each  byte  of  binary 
0's  and  l's  is  up  to  the  implementation.  A  byte  could  be 
considered  to  be  a  character,  an  integer,  or  control 
information.  For  this  reason,  all  declarations  of 
structures  which  are  used  as  overlays  for  the  networking 
packets  are  declared  as  "bit(S)"  in  PL/I-36.  The 
interpretation  of  these  as  characters  or  control  is  no  real 
problem.  However,  when  a  particular  byte,  or  more  normally 
a  group  of  two  bytes,  are  to  be  considered  as  integers,  then 
it  was  necessary  to  overlay  the  bit  string  with  a  based 
variable  whose  type  was  declared  as  "fixed”,  "fixed  bin(7)’, 
or  "fixed  bin(15)"  in  PL/-S6.  This  is  because  run  time 
conversions  of  bit  to  fixed  values  caused  unexpected 
results  . 

Another  important  point  is  the  manner  in  which  PL/I-S6 
stores  integers  and  hexadecimal  values.  A  two  byte  integer 
is  stored  with  the  least  significant  byte  preceding  the 
most  significant  byte  in  memory.  Thus  overlaying  a  ’fixed" 
or  "fixed  bin(15)"  over  the  length  bytes  of  the  NI3010 
receive  frame  is  acceptable  because  the  protocol  says  that 
the  least  significant  byte  is  first  in  memory  followed  by 
the  most  significant  byte,  just  as  in  PL/I-36.  This  will 
not  work  for  the  length  bytes  as  they  are  stored  for  the 
Internet  Protocol.  There  the  two  byte  integer  value  is 
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memory,  it  must  do  so  to  the  portion  of  the  data  segment 
which  is  in  the  extended  memory. 

The  ’m[0]  ’  data  parameter  tells  the  linker  to  allocate 
no  additional  memory  for  the  data  section  of  the  command 
file.  This  prevents  the  overwriting  of  command  file  data  hy 
the  transfer  of  packets  into  the  extended  TPA  which  lies 
within  the  data  segment  address  space. 

The  "ad[82]”  data  parameter  gives  the  total  number  of 
additional  paragraphs  to  allocate  to  the  data  segment  of  the 
command  file.  This  enables  the  user  to  run  either  LISTEN  or 
DEMO  within  the  local  memory  of  the  iSBC  86/12. 

The  combination  of  the  linker's  loading  of  the  data 
segment  register  with  800  hexadecimal,  the  PL/I-86  "ur.spec  ’ 
built  in  function,  and  the  PL/I-86  pointer  based  structures, 
allows  the  programmer  to  locate  a  template  in  the  extended 
TPA  for  the  transmit  data  blocks  and  receive  data  blocks 
for  the  NI3010  DMA  operations.  Eor  Instance,  in  the  LISTEN 
program,  the  linker  has  loaded  the  data  segment  register 
with  830  hexadecimal,  and  the  receive  data  block  is  based  on 
a  pointer  whose  value  is  forced  to  be  8000  hexadecimal  by 
the  PL/I-86  statement  "unspec'x)  =  '8000'b4;"  Thus  the 
address  of  the  receive  data  block  is  the  sum  of  the  8000 
hexadecimal  and  the  800  hexadecimal  (left  shifted);  this 
yields  an  address  of  10000  hexadecimal,  which  is  the  first 
byte  of  the  extended  TPA. 
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APPENDIX  A 


PROGRAMMING  NOTES 

There  are  several  features  of  PL/I-86  and  LINK-86  that 
are  important  to  understand  so  that  the  programs  and  linking 
insructions  for  them  can  he  understood. 

The  linking  command  for  both  LISTEN  and  DEMO  are  quite 

similar?  the  only  real  differences  are  the  assembly  language 

modules  that  are  linked  into  each.  The  main  point  to 

understand  about  them  is  the  parameter  listing  for  the  PL/I- 

36  program.  The  linking  commands  used  were:  "link86 

listen[i]’  and  "link36  demo[i]"  where  the  [i]  option  was 

an  input  file  for  the  linker.  The  input  file  was: 

deno  [data  [abs  [800]  ,m[0]  ,ad  [82]  .map  [al  1]  ]  , 
cksum,  add32bit .xternasy 

The  first  parameter  for  DEMO  says  to  load  the  data  segment 
register  of  the  8086  microprocessor  with  902  hexadecimal. 
This  forces  the  data  segment  of  64K  bytes  to  run  from  the 
base  address  of  8030  hexadecimal  to  17fff  (remember  that 
address  registers  are  left  shifted  by  four  bits  before  the 
offset  is  added)  .  Thus  one  half  the  data  segment  is  on 
86/12  SBC  onboard  memory  and  the  other  half  of  the  data 
segment  is  located  in  the  extended  TPA.  The  reason  for  this 
straddle  of  onboard/extended  memory  is  that  the  onboard 
memory  is  strapped  so  that  it  is  'inaccessible  from  MULTIBUS. 
Since  the  MI3G10  needs  to  transfer  packets  to/from  host 
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VI  .  CONCLUSIONS 

The  goals  of  the  thesis  were  met  by  the  demonstration 
program's  showing  the  viability  of  a  microcomputer  based 
process  logging  into  a  VAX  UNIX  system  over  the  Ethernet. 
The  basic  information  on  the  protocols  used  is  available; 
they  can  be  implemented  on  a  16  bit  microprocessor?  PL/I  is 
sufficiently  flexible  to  allow  the  linking  of  the  assembly 
language  routines  necessary  to  write  the  device  driver  for 
the  MI3310  board  and  to  perform  32  bit  arithmetic  and  16  bit 
checksums . 

Now  that  the  fundamental  concepts  have  been  recorded,  it 
is  necessary  to  implement,  in  a  modular,  layered  approach 
the  full  remote  login/termi  r.al  capabilities.  Cnee 
accomplished,  it  would  be  possible  to  use  the  program  for 
communication  over  the  ARPANET.  By  logging  into  the  Vex 
UNIX  system,  its  full  networking  capabilities  can  be 
utilized. 
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operation  will  wipe  out  all  buffers  and  registers  on  the 
NI3?1£  beard.  3oth  LISTEN  and  DIMO  will  issue  a  warning 
message  when  there  is  a  size  error  and  then  terminate. 

Pl/I-86  input/output  routines  are  not  re-entrant. 
Therefore,  when  doing  any  i/o,  it  is  necessary  to  do  so  in 
the  N 1 301 0  board  interrupt  handler  or  make  calls  through 
this  handler.  Since  the  first  steo  of  the  board  interrupt 
handler  is  to  disable  the  board  interrupts,  all  code  will 
execute  to  completion  without  interruption?  therefore,  no 
i/o  routines  will  be  interrupted.  If  they  were, 
unpredictable  results  on  the  terminal  will  occur. 


packets  on  that  connection.  The  next  time  the  Sun  attempts 
a  remote  login,  the  VAX  system  replies  to  the  initial 
reouest  not  with  an  "ack.syn'  packet  hut  with  a  broadcast 
packet.  The  protocol  for  this  was  not  investigated,  but  a 
cursory  examination  revealed  that  the  intent  of  the  packet 
appeared  to  be  an  update  to  VAX  UNIX  system  address  tables 
that  were  altered  when  the  previous  connection  from  the  same 
source  terminated  abnormally.  For  further  program 
development,  this  can  be  avoided  by  merely  logging  back  into 
the  VAX  from  the  Sun  before  attempting  the  next  running  of 
DEMO . 

When  running  either  LISTEN  or  DEMO,  the  program  can  run 
to  normal  termination  or  be  terminated  early  if  hung  up  or 
the  desired  number  of  packets  has  not  been  received.  On 
the  AEGIS  multiuser  system,  this  can  be  accomplished  by 
either  resetting  the  MULTIBUS  cluster  or  resetting  only  the 
£6/12  SEC  in  use.  If  either  program  has  been  terminated 
early  by  resetting  the  S6/12  SBC,  then  the  next  time  either 
one  is  rur.  an  extra  byte  of  data  is  transferred  from  the 
board  into  the  extended  TP^.  When  the  receive  data  block  is 
overlaid  on  this  portion  of  memory,  it  is  off  by  this  one 
byte,  thus  causing  the  program  to  improperly  determine  the 
size  of  the  received  packet.  This  can  be  avoided  by  always 
resetting  the  MULTIBUS  cluster  before  running  the  program. 
This  has  the  same  effect  as  turning  off  the  power  to  the 
board  and  then  turning  it  back  on.  This  power  down 
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/*  note:  lew 


==>  initialization 
control 
word 


ocw  ==>  operational 
c  ommand 

word  */ 


cwl  by  '13'b4, 

/*  single  PIC  configuration,  edge 
trlgsered  input  */ 

cv2  by  '4?'b4, 

/*  most  significant  bits  of  vectorin 
byte;  for  an  interrupt  5, 
the  effective  address  will  be 
(icv2  +  interrupt  #)  *  4  which 

will  be  (40  hex  +  5)  *  4  = 

114  hex  -f / 


icw4  by  '0f'b4, 

/*  automatic  end  of  interrupt 
and  buffered  mode/master  */ 
ocwl  by  'Sf'b4, 

/*  unmask  interrupt  5  r b i t  5)  and 
mask  all  others  */ 

/*  end  8259a  codes  */ 


/*  include  constants  specific  to  the  MI 30 10 
beard 


*/ 


%include  'listen. del 


/*  see  APPENEIX 


n 

u- 


/*  Main  Body  */ 


/* 

disable  the  n i3310  board  so  that  it  does  not  inter ru 
this  new  initialization 

*/ 

call  write_io_port(interrupt_enable_register  , 
disable_ni3010_interrupts); 


/* 

initialize  ni3310 ,  PIC,  and  CPU  interrupts 

*/ 

call  read_io_port  (command_status_register,reg_value  )  ; 

call  perform_command(go_of fline) ; 

call  perform_command(reset ) ; 

call  ini t iali ze_pi c ; 

call  initiali ze_cpu_interrupts* 

/* 

set  the  receive  block  base  address  at  3030  hex, 
the  first  memory  location  in  the  extended  tpa? 
fill  the  extended  tpa  with 
V 

unspec ( rec_blk  ptr)  =  S000'b4; 

do  i  =  1  to  15000J 

fill_xtpa(i)  = 

end ; 


/* 

user  interface 

*/ 

put  list  (clearscreen) ? 
put  skip; 

DUt  edit  ((border  (i)  do  i  =  1  to  83))  (a); 

put  skip  list  (  'SMTER  1  FOR  HEX  PRINTOUT: ENTER  2  FOP  PINAP.F 

put  skip? 

get  li s t ( ou tput_type ) ; 
put  skip; 

open  file  (packet)  stream  output; 

put  skip  list('How  many  packets  do  you  wish  to  receive'); 
put  skip; 

get  list(user  desires); 


put  ni3?10  online  and  prepare  to  receive  packets 

*/ 

call  perfo rn_c cmmand (go_online); 
call  perf orm_command(  set_promiscuous_mode  ) ; 
copy_ie_regis ter  =  recei ve_block_a va i lable J 
call~write_io_port  (interrupt _enable_r eg ister, 

receive  Slock  available); 


/* 

wait  until  user  specified  number  of  have  been  packets 
received 

*/ 

do  while  ( number_of _packet s  <  user_desires  ); 
end? 


/* 

reset  the  ni3010  to  clear  buffer?  close  file 

#/ 

call  perf orm_command  (reset); 
put  skip  (3); 

put  edit  ((border  (i)  do  i  =  1  to  30))  (a); 
put  skip  (2); 
close  f ile ( packet ) ; 

/*  end  main  body  */ 


This  module  initailizes  the  programmable  interrupt 
controller  on  the  86/12  STC 

initialize_pic:  procedure; 

declare 

vri te_i o_port  entry  (bit  (3)  ,  bit(B) )» 
call  wri te_io_port  ( icwl_port_address , icwl ) ; 
call  wri te_io_port  ( icw2_port_address ,icv2  ■ ; 
call  wri te_io_port  ( icw4_port _addres s , icw4) ? 
call  wri te_io_port  ( ocw_por t_addres s f ocwl ) ; 


end  ini tialize_pic? 
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* 


>  .r  •  (*  * 


This  module  sends  to  the  \’ 1 3213  board  the  command  receive 
in  the  parameter  list.  It  then  waits  to  see  if  the  commar. 
has  been  successfully  carried  cut  by  the  board. 

V  ##  ^  £*£  #*£**:**  5l=  :;<***  5*  fc  5*  ##  Sft  *  =r  s::  * 


perf  orm_comma  r.d  :  procedure  (command); 

declare 

command  bit  (S)  , 
reg  value  bit  (5  )  , 
srf'bit  (S)  . 

wri te_io_port  entry  (bit  (F )  ,bit  (6)  ), 
read_io_port  entry  (bit  (3)  ,bit  (3)  ); 


srf  =  '2  ' b 4 ; 

call  write  io_port  (command  resister  .command  ) »' 
do  while  ( Tsrf  S.  '0l'b4)  =  700'b4); 

call  read  io_port  (interrupt  status_reg, 

srf); 

end;  /*  do  while  */ 

call  read_io_port  ( c ommand_status_regi s ter , 
reg_value ) ; 

if  (reg  value  >  '01 'b4)  then 
do; 

/*  not  ( SUCCESS  or  SUCCESS  with  Retries)  */ 

put  skip  edit  (  '***  ETHERNET  Board  Failure  **#') 
( co 1 ( 35 )  ,  a  ) » 

stop; 
end  5 


end  perf crm_command J 
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This  module  is  called  by  the  assembly  language  interrupt 
routine.  It  handles  three  NI3-010  interrupts:  the  receive 
block  available,  receive  dma  dene,  and  the  transmit  dma  dor. 
interrupts.  It  also  checks  for  the  MI3012  anomaly  an 
prints  out  an  error  message  and  terminates  the  program 
should  the  anomaly  exist.  The  receive  block  is 
repositioned  in  memory  after  each  packet  has  been  dma'ed  to 
memo  ry . 

X:#*:*;*:*::::*#*::*  jfcjit##  *  jjt a;:##  #  XsjjsXt  ~  =r*  sir:*##:*## / 


HL_interrupt_handler :  procedure  external? 

declare 

wri te_ic_?ort  entry  (bit  (8)  .bit  (8)  ), 
read_Io_?ort  entry  (bit  (8)  ,bit  (8)  ), 
enable_npu_interrupts  entry, 

disabli_cpu_interrupts  entry, 

write_bar  entry  (pointer); 


/* 

don't  let  anything  interrupt 

*/ 

call  disable_cpu_interrupts ? 

call  write_io_port( in te rrupt_enable_regi s te r  , 

disable_ni3?10_ interrupts ) ; 


if  ( copy_ie_regis ter  =  recei ve_block  available)  then 
do ; 

call  write_bar  ( adir ( receive_4ata_block  1 ) ; 
call  wri te”io_port  high_byte_count_reg,'06'b4); 
call  wri te_io_po rt (lov_byte_count_reg, '00 'b4) ; 

/*  initiate  receive  DMA  */ 

copy_ie_register  =  recei  ve_dma_dor.e ; 

call  wri  te_io_po  r  t  <’interrupt_enable_register, 

recei ve_dma_done ) ; 

end?  /*  if  receive  block  available  */ 


P-  ID 


if  ! r opy_ie_regi s ter  =  recei ve_dma_dor.e )  then 
do; 

number_cf_packets=number_of_packets  -  l; 
size_ptr= 

addr ( receive_data_block.f rame_lenath_lsb) ; 
/*  check  for  ni3010  anomally  and,  if 
present  set  number  of  packets  so  that 
we  drop  through  to  the  end  of  the 
program  */ 

if  (size  >  1522  !  size  <  64)  then 
do? 

put  skip  list ('SIZE  ERROR'); 
number_of _packet s  =  user_des i res  I 
end ; 

else 

call  print_packet ; 

/*  below  repositions  the  receive  data 
block  overlay  */ 
rec_blk_ptr  = 

addr(receive_data_block.data(size  -  4)); 

If  (number_of_packets  )=  user_iesires )  then 

call  wri te_io_port ( interrupt _enable_regis ter , 

di sable_ni3310_interrupt  s ) J 

else 

do; 

eopy_ie_register  =  receive  block_ava liable ; 
call  wri  te_i.o_pcrt  (interrupt_enable_retfis  ter  , 

recei ve_block_available ) ; 

end; 

end?  /*  if  receive  dma  done  */ 


else 


if  (copy_ie_register  ■=  t  ransmi  t_dma_done  ) 
then  do? 

copy_ie_regi ster  =  recei ve_block_available ; 
call  write_io_port' interrup t_enable_resis t er , 

receive  block  available); 


end?  /*  if  transmit  dma  done  */ 
end  HL  interrupt  handler; 


This  module  is  ■'ailed  from  the  HL  interrupt  routine, 
prints  each  packet  received  into  the  file  PACKET.DAT. 
output  is  either  in  hexadecimal  or  binary,  as  selected 
the  user. 


print_packet : 


procedure ; 


/* 

print  out  destination , source , frame  status,  frame 
length,  and  frame  type. 

-/ 

if  (receive_data_block .destination_address_f  =  '2?'b4) 
then  nut  fileTpacket)  skip  list 

( '  from  VAT  to  SUM' ); 

else  if  ( receive_data_bl ock .de s t ina t i on  address  f  = 

'7f’b4) 

then  put  file(oacket)  skip  list 

( '  *  from  SUM  to  VAX') ; 

else  put  file(packet)  skip  li st ( 'BROADCAST  PACKET'); 

put  file ( packet )  skip? 

put  file(packet)  edit( 'frame  status  = 

receive_data_block . f rame_s ta tus ) (skip , a , b( S) )  i 
put  file(packet)  skip  list 

('frame  length  =  '.size)? 

put  file(packet)  edit( 'type_field_a  =  ', 

receive _data_b lock. type_f ield_a ) (skip,a,b(8)); 
put  file(packet)  edi t ( 'type_f ield_b  =  ', 

receive _data_b lock. type _field_b)(ski?,a,b( 8)); 


/* 

this  section  prints  out  the  IP  and  TCP  headers 
in  either  hex  or  binary 

*/ 

put  file( packet)  edi t( 'the  data  is : ' ) ( skip  ,a ) 5 
put  file(packet)  skip; 
do  i  =  1  to  23; 

put  file(packet)  skip; 

/*  is  user  selected  hexadecimal  output  */ 
if  (output_type  =  'l')  then 

put  file^packet)  edit('4ata  ',i,'=  ', 
recei ve_data_block .da ta ( i  ) , 'da ta  ',(i  -  23),'=  ', 
receive_data  block. data(i  +  23)) 
(a.f(4),a,b4(2),col(30),aff(4).a,b4(2)); 


else 


put  file (packet)  eiitv  data  ,  i,  = 
receive_data_block .data ( i  ) , 'da ta  ',(i  22),' 

recei ve-da t a_bl ock  .da t a ( i  +  20)) 

(a,f (4)7a,b(8) , coif  30) ,a,f (4) ,a,b(8)) ; 

end  J 

put  file ( packet )  skip; 


/* 

prints  out  data  portion  of  TCP  in  either  hex 
or  binary 

*/ 

do  i  =  41  to  (size  -  18) ; 
put  file(packet)  skip; 

/*  if  user  has  selected  hexadecimal  output  */ 
if  (output_type  =  'l')  then 

put  file(packet)  edit('data  ',i,'  = 

recei're_data_block.data(i))(a,f(4),a,b4'2)); 

else  , ,  ,  ,  , 

put  file(packet)  edit!  data  ,i,  =  , 

receive _data_block.data(i) ) (a , f (4) ,  a ,b  ( 8 ) ) ; 

end ; 

put  f i le ( nacket )  skip  list  ( next _pa*e ) ; 


end?  /*  print_packet  */ 


end;  /*  procedure  listen  */ 
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APPENDIX  D 


LISTING  OF  DEMONSTRATION  PROGRAM 
demo:  procedure  options  'main); 

/*!!  1 1 1  !  1  !!!!!!!!!!!! I !!!! I !!!!!!!! !! I !!!!!!!!!!!!!!!!!!!!!  ! 

date:  20  November  1984 
author:  John  Donald  Reeke 

This  program  demonstrates  that  a  CPM-86  process  running  on 
the  AEGIS  multiuser  system  can  remotely  login  over  an 
Ethernet  to  the  VAX  11/780  running  4.2  ESD  UNIX.  It  is 
designed  to  mimic  the  remote  login  of  the  Sun  Workstation  to 
the  VAX  and  therefore  uses  the  Sun's  Ethernet  address, 
source  address,  and  source  port.  The  program  is  intended  to 
only  go  as  far  in  the  remote  login  process  as  is  necessary 
for  th  :  VAX  to  send  the  data  "Password’  to  this  process. 
Inbound  packets  from  the  VAX  are  processed  only  for  their 
sequence  number  and  whether  or  not  they  contain  data. 

It  initializes  the  ni3010  board  and  then  asks  the  user  how 
many  packets  to  capture  before  termination  of  the  program. 
Since  this  program  captures  all  packets  on  the  Ethernet, 
including  its  own  transmissions,  a  minimum  of  22  packets 
should  be  selected.  Next  the  user  is  prompted  for  the 
destination  of  the  remote  login.  All  packets  received  are 
placed  consecutively  in  memory;  no  contents  are  displayed  to 
the  terminal.  It  is  necessary  to  look  in  memory  with  a 
debugging  tool  such  as  DDT-86  to  examine  the  packets. 

Before  executing  this  program,  ensure  that  the  VAX  and  the 
Sun  have  logged  in  to  each  other  to  preclude  broadcast 
packets,  as  discussed  in  the  body  of  the  thesis,  from  being 
utilized  in  the  login  procedure.  Also,  the  Sun.  must  be 
turned  off  so  that  it  does  not  put  any  packets  on  the 
Ethernet . 

f  !!!!!!!!  I  !!!!!!!  !  MI  !!!!!!!!!  f  !!!!!!!!!!  H!  !!!!!!!!!!!!!  */ 
declare 


/*  The  source  address  is  included  in  the  transmit 
data  block  because  the  ni3010  is  more  efficient 
with  the  automatic  insertion  of  the  source 

suppressed  by  the  "clear  insert  source  address" 
command  */ 

1  t ransmi t_data_bl ock  based  ( trans_blk_ptr ) , 

2  des tination_address_a  bit  (8), 

2  destination_address_b  bit  (8), 

2  destination  address  c  bit  (8), 


2 

les  tinat ion_addre 

s  s  _d  bit 

(a) , 

2 

destination  aidre 

s  s  e  bit 

(3)  . 

■.  *  .< 

2 

destination  address  f  bit 

;s) . 

2 

s  ource_address_a 

bit  (8), 

2 

s  ource_address_b 

bi t  '8)  , 

2 

source  address  c 

bit (8) , 

Iv’.ai 

2 

sou  rce”address_d 

bit'S) , 

_  v 

2 

s  ource_addre  ss_e 

bit (8), 

2 

s  ource_address  _f 

bit  '8) , 

2 

type_f ield_a 

bit (8) , 

2 

type_f ield~b 

bit !8) , 

.  *■*„  ^ 

i 

data  (100) 

bit (8) , 

1 


receive_da  ta_bl  ock  based  (  rec_blk  ptr), 


2  frame_status 

bit 

(37  , 

2  null_byte 

bit 

(8)  . 

2  f rame_length_l sb 

bit 

(8)  , 

2  f rame_length~-nsb 

bit 

( a )  , 

2  destination_address_a 

bit 

(a)  , 

2  destination_address_b 

bit 

(8 )  , 

-  1 

2  des tination_addr es s_c 

bit 

(8)  . 

*/  1 

2  des t inat ion_addres s_d 

bit 

(8)  , 

2  des tination_address  e 

bit 

(6)  , 

2  des tination_address_f 

bit 

(8)  , 

.  / 

2  s ource_address_a 

bit 

(8)  , 

2  source_address_b 

bit 

(8)  , 

,*  * 

2  source~address~c 

bit 

(8)  , 

■ 

2  s ource~address_d 

bit 

( 8 )  , 

2  source_address  e 

bit 

(8)  , 

2  source~address_f 

bit 

(8)  . 

m.  . 

2  type_field_a 

bit 

(8)  , 

2  type  field  b 

bit 

(8)  , 

J 

2  data  (15007 

bit 

(8)  , 

*  *  ' 

2  crc_msb 

bit 

(8)  , 

,  « 

2  crc_upper_middle_byte 

bit 

(8)  , 

*.'*.r* 

2  crc7lower_midile_byte 

bit 

(8)  , 

k*  - 

*  crc_lsb 

bit 

(a)  , 

/*  how  many  packets  does 

user 

vant  to  receive  */ 

user_desires  fixed, 


/*  size  of  the  Ethernet  Packet  */ 
size_ptr  pointer, 

size  fixed  bin(15)  based  (size_ptr), 

/*  pointers  to  position  overlays  in  memory  */ 

( trans_blk_ptr , rec_blk_ptr)  pointer, 

/*  number  of  packets  received  by  this  program  */ 
numter_of _packets  fixed  static  init(0), 

copy_ie_reeister  bit(8), 
i  fixed  bin  (15) , 
reg_value  bit  (8)  , 
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/*  Modules  external  to  this  nodule  */ 


add22bit  entry  ( hi t { 3 ) , hi t (6 ) , bi t ' S  ) )  , 

cksum  entry  (  bit  (£),  fixed  hi  n  (7  )  ,  bi  r.  i  16)  )  , 

vrite_io_?ort  entry  (hit  3)  ,tit  (S'  ), 
read_io_port  entry  (bit  ;3)  ,oit  (S)  ), 
initiali  ze_cpu_ir.  terrupts  entry, 

enable_cpu_interrupts  entry. 

disable_cpu_interrupts  entry, 

write_bar  entry  (pointer); 

/*  end  external  nodule  listing  */ 


%replace 

/*  codes  for  programmable  PIC  on  S6/12  SBC; 
note  that  icw2,icw4,  and  ocw  are  the  same 


icwl_port_address 
i cw2_por  t_address 
icv4_pcr  t_address 
ocw_port_address 


by  'c0'b4, 
by  'c2'b4, 
by  'c2'b4, 
by  "c2'b4, 


/*  note:  icv  ==t>  initialization 

control 

word 

ocw  ==>  operational 
command 

word  */ 


icwl  by  '13'b4, 

/*  single  PIC  configuration,  edge 
triggered  input  */ 

icw2  by  '40'b4, 

/*  most  significant  bits  of  vectoring 

byte;  for  an  interrupt  5, 
the  effective  address  will  be 
(Icw2  *  interrupt  #)  *  4  which 
will  be  (40  hex  +5)  *  4  = 

114  hex  #/ 

ic w4  by  '0f  'b4 , 

/*  automatic  end  of  interrupt 
and  buffered  mode/master  */ 

ocwl  by  '3f'b4, 
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/*  unmask:  interrupt  5  (bit  5)  and 
mask  all  others  *  ' 

/*  end  8259a  coles  */ 


true 

by 

'l'b. 

false 

by 

'0  'b  , 

vai 

by 

'7 f  'b4 

clearscreer. 

by 

z  > 

/*  include  constants  specific  to  th 
board  and  IP/TCP  declarations 


^include  'vt.dcl'i 


■»  ID 


\  • 

y  f 


/••'  Main  2ody  */ 

besi r J  /*  initialize  the  process  */ 

del  f  ill_xtpa  ( 13200  )  char  based  ( trars_blk_pt r 

/*  disable  the  ni 3213  so  that  it  does  not 
interrupt  this  initialization  */ 

copy_ie_regist er  =  disable_ni3210_in terrupts ; 
call  write _io_?ort( inter rupt_enable_regi st er , 

disable_ni3010_interrupts) ; 

call  read_io_port  ( command_status_register  , 

reg_value); 

call  perf  orm_command  :go_offline); 
call  perf orm_command ( reset )  5 

/*  clear  terminal,  base  the  transnit  block  and 
the  receive  block  in  the  extended  t pa ,  ar.i 
fill  the  tpa  with  asteriks.  #/ 

put  list  ' cl earscreen  ) ; 
unspec'trans  blk_pt r )  =  '8221' b4 ; 
uns pec ( rec_blk_ptr  )  =  'S620'b4; 
do  i  =  1  to  12C22I 

fill_xtpa(i)  = 

end ; 


/*  initialize  the  pic  */ 

call  wri te_i o_por t  ( icwl_port_addres s , icwl ) ; 
call  wri te_lo_port  ( icw2~port_addres s  ,  icw2  ) ; 
call  wri te_i o_port  ( icw4_port_address , icw4  ) ; 
call  wri te_io_port  'ocw_port_adiress  ,ocwi  ) ; 

/*  end  initializing  the  pic  */ 

call  initialize^ pu interrupts; 
call  initial ize_headers ; 

call  perf orr_c emmand  (2o_online); 

call  perform _command  'set_promiscuous_mode)  ; 

call  perform_command(clear_ir.sert_source_aidress)  ; 

/*  user  interface;  perform  all  of  this  with  the 
board  disabled  so  that  the  1/0  runtime 
routines,  which  are  not  ~e -en  t  r  ar.  t .  will  net 
be  interrupted  .  */ 

put  skip  list('how  many  messages  to  receive'); 
eet  list  ( user _d e s i re s  ) ; 
call  ma ke _e t he r re t _head e r ; 

end.’  /*  end  initialization  */ 


S4 


/*  enable  the  board  for  the  remote  login  */ 
c0p.v_ie_re2l.ster  =  receive_blork_ava  liable  : 
call  write_io_port  (  interrupt_enable_regis  ter  , 

recei v e_block_ available); 

call  remote_login; 

call  perf orm_conmand  (reset); 

/#  end  main  body  */ 


'his  module  is  called  from  the  main  body  cf  this  program. 
:t  initializes  the  I?  and  TCP  headers,  the  Ethernet  frame 
;ype  filed,  and  several  other  variables  for  use  in  the 
■emote  logn.  The  IP  header  source  and  destination  addresses 
ire  the  addresses  of  the  VAX  and  Sun  on  the  AP.PANET. 


.initialize  headers: 


procedure; 


/*  initialize  the  IP  header;  sons  values  are 
completely  arbitrary  in  this  program:  for 
instance,  the  id  lsb  and  id  msb  */ 


uns  pec ( int_hdr _ 
internet_header 
inter  r.et_header 
internet_header 
inter  net_header 
internet_header 
internet_header 
int ernet _header 
inter  net_header 
int  er  net  _heade  r 
internet_header 
inter net_header 
internet_header 
internet_header 
intemet_header 
internet_header 
internet_header 
int  ernet  _heade  r 
internet  header 


ptr  ) 

.version_ihl  = 

. type_of _service 
.length_mst  = 
.ler2th_lsb  = 
,id_msb  = 

.id_lsb  = 

.flags  frag  = 

.  t  tl  = 

.protocol  = 

. hdr _ch°cksun  = 
.source_a  = 
.source_b  = 
.source_c  = 

.  s ounce _d  = 
.dest_a  = 

.dest_b  = 

.dest_c  = 

.dest  d  = 


'900  f 'b4 ; 
'45'b4; 
'00 '  b4 ; 

'00 'b4; 

'2c'c4; 
'23 '  b4 
'4e ' b45 
'0030  'b4; 
'0f 'b4; 
'06'b4; 
'0000'b4: 
' Cc  ' b4 ; 
'39 '  b4! 
'c3'b4; 
'wl  'b4i 
'c0'b4I 
'09'b4J 
'c8'b4J 
'03'b4; 
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UNCLASSIFIED 


REMOTE  TERMINAL  LOGIN  FROM  A  MICROCOMPUTER  TO  THE  UNIX 
OPERATING  SVSTEM  USING  ETHERNET  AS  THE  COMMUNICATIONS 
MEDIUM (U)  NAVAL  POSTGRADUATE  SCHOOL  MONTEREV  CR 
J  D  REEKE  DEC  84  F/G  9/2 


/*  -initialize  the  TCP  header?  some  values  are 
completely  arbitrary?  for  instance,  the 
sequence  number,  source  port?  M0T2:  the 
source  port  will  be  stored  in  memory 
as  03  ff  hex  and  the  destination  port 
will  be  stored  as  02  01  hex.  */ 


unspec( tcp_hdr_ptr )  = 
tcp_header . source_port  = 
tcp_header .des t_port  = 
tcp_header  .of f set  = 
tcp  header. control  = 
tcp'header .window_msb  = 
tcp_header .window_lsb  = 
tcp~header .checksum  = 
tcp_header . urgent  pointer  ® 
tcp~header.data( lT  = 
tcp_header .data(2)  = 
tcp_header.data(3)  = 
tcp_header .data(4)  = 
tcp_header .data(  5)  = 
tcp_header .data(  6)  = 
tcp~header . sequence_num ( 1 )= 
tcp_header .seouence_num( 2)  = 
tcp_header .sequence_num(3)  = 
tcp_header .seouence_num(4)  = 


'3023 'b4? 
'f  f03'b4? 
'0102 'b4? 
'60 'b4? 


syn? 

'0e'b4? 


'00'b4? 
'0000 'b4I 
'0000 'b4? 
'0  2'b4? 
'04'b4? 
'04 'b4? 
'00'b4? 
'30 'b4? 
'00 'b4? 
'02'b4? 


'Ic'b4? 
'29 'b4? 
'01  'b4  ? 


do  i  M  to  41 

tcpjieader  .ack_num(i )  =  '00'b4? 
inc_seo_num(i )  =  '00'b4? 
seg_ackfi)  =  '00'b4? 

end? 

seg_len  =  '00 'b4? 

transmit_data_block.type_field_a  =  '0S'b4? 
transmit_data_block.type_field~b  =  '03'b4? 


/*  initialize  headers  */ 


/  $  $  Sic  <e  if  if  if  *  *:  ajc  sj:  #  #>i«j{tjSs!c<s^t«##  $  j*  #  *  #  *<>;«##  sit  >K  sjc  *  ##  *  #  #  He 

This  module  is  called  from  various  other  modules.  It  sends 
to  the  ni3010  hoard  the  command  received  in  the  parameter 
list.  It  then  waits  tc  see  if  the  command  was  cuccessfully 
carried  out  by  the  hoard.  If  the  command  was  not 
successful,  an  error  message  is  displayed  and  the  program 
terminates . 


perf orm_command :  procedure  (command); 

declare 

command  hit  (S)  , 
reg_value  hit  (8)  , 
srf-bit  (8)  , 

write_io_port  entry  (hit  (8)  ,hit  (8)  ), 
read_io_port  entry  (hit  (8)  ,bit  .(£)  ); 


srf  *  '0'b4J 

call  write_io  port  (command  register, command); 
do  while  'Tsrf  &  '01  'b4)  =  T00'b4); 

call  read  io  port  (interrupt  status  reg, 

~  "  srf)? 

end;  /*  do  while  */ 

call  read_io_port  ( command_status_register, 

reg  value); 

if  (reg_value  >  '01  'b4l  then 
do ; 

/*  not  (SUCCESS  or  SUCCESS  with  Retries)  */ 

Dut  skip  edit  (  '#**  ETHERNET  Board  Failure  ***') 
(col(35)  ,a) ; 

stop; 

end;  /*  itd  #/ 


end  perf orm_command J 


/  Hf  #  #  if  #  if  5je  *  >i«  #  v  *  *  aje  $  *  *  #  #  #  * #  *t  *s  $  #  t'f if  $  *«  if  a)t  a*  *  *t  #  #  #  #  #  <:  # sjt  sjc  j|t  sp  #  ajcsp  >■«  ap  ap  #  j(c  ap  ap 

This  nodule  is  called  from  the  main  body  of  the  pro2ram.  It 
prompts  the  user  for  the  destination  of  the  remote  losin. 
The  Ethernet  address  of  the  Sun  is  used  as  the  source 
address  of  the  Ethernet  packet. 

ap  aft  ap  ap  ap  ap  ap  ap  >!S  ap  ap  3ji ap ap  ap  ap  ap  ap  ap as  *  ap  ap  sjc  sit  ap  5;-.  ap  ap  ap  ap  ap  ap  ap ap  ap  ap  ap  ap  ap  ap  ap  *  ap  ap  *  ap ap ap  ap  ap  ap  *  ap  ap  ap  *  ap  / 


make_ethernet _header :  procedure! 

del 

choice  char(l); 


choice  =  - ! 

do  while  (choice  ”=  'a'  S.  choice  “=  'b'  & 
choice  ~=  'cy  &  choice  ~=  'd'); 
put  skip  list 

('Chose  from  below  menu  the  destination  of  your  packet'); 
put  skip! 
put  skip  list 

('  NOTE:  enter  only  lower  case  letters'); 

put  skip! 
put  skip  edit 

('  a.  VAX  UNIX','  b.  SUNl')(a,skip,a,skip); 
put  skip  edit 

('  c.  MYSELF','  d.  MDS') fa,skip,a); 
put  skip; 

get  edit (choice )  (a  (1 )) ; 
put  skip? 

end;  /*  do  while  */ 


if  (choice  =  'a'  |  choice  =  'c'  !  choice  =  'd')  then 
do ; 

transmit_data_block .destination_address_a  -  '02 'b4; 
transmit_data_block .iestination_address_b  =  '07'b4? 
transmit~data~block.destination~address~c  =  '01  'b4; 
transmit]]data~block  .destination~address~d  =  '00'b4J 
end? 
else 
do ; 

transmit_data_block .destinati on_address_a  =  '02'b4; 
transmit3data~block.destination~address”b  =  '60'b4J 
transmit3<iata“block  .destination3address_c  =  '9c'b4J 
transmit~data~block.destination”address~d  =  '00 'b4! 
transmit_data~block  .destination”address_e  -  '42'b4»* 
transmit~data-block.destination"address-f  =  '27'b4; 


if  choice  =  'a  then 
do; 

transmit  _data_t lock:  .dest  ina  tion_address_e 
transmit  ji  a  t  a  "block  .dest  ina  tio.n~address_f 
end; 


'07 'b4J 
'7f 'm; 


else  if  choice  =  'c'  then 
do ; 

transmit _data_block .dest ina tion_add res s_e 
transmit  [[data’blcck .des ti nation ’address ~f 
end? 

else  if  choice  =  'd '  then 
do; 

transmit _data_block .dest ina t ion _addr ess _e 
transmit ~data”block .dest ina tion~address_f 
end» 

transmit_data  block. source_address_a  =  '02'b4; 
transmi t_data2block . scurce~address_b  =  '60'b4J 
transmi t_data_block .source_address_c  =  '8c'b4J 
transmit_data_block.source_address_d  =  '00'b4; 
transmit~iata3block.scurce~address_e  =  '42'b4J 
transmit  da ta'block. source  address  f  =  '27'b4» 


'03  'b4J 
'ea  'b4; 


'04 'b4 ; 
'0a  'b4 ; 


end;  /*  make  ethernet  header  #/ 


This  module  is  called  from  the  remote_login  modul 
parameter  is  the  number  of  bytes  in  the  data  portion 
packet  to  be  transmitted,  i.e.  the  number  of  byte 
IP/TCP  protocols.  The  parameter  is  incremented  by 
number  of  bytes  in  the  Ethernet  header  of  the  transm 
block.  Should  the  clear  insert  physical  addrs 
change,  then  it  should  be  incremented  by  8  vice 
parameter  passed  is  a  fixed  bin'?);  it  must  be  o 
with  a  bit(3)  variable  sc  that  it  can  be  written  ou 
board's  low  byte  count  register. 


e.  The 
of  the 
s  in  the 
14,  the 
it  data 
ss  mode 
14.  The 
ver layed 
t  to  the 


transmi t_packet : 


procedure  ( low_byt_cnt ) ; 


declare 

wri te_io_port  entry  (bit  (8)  .bit  (8)  ), 
read  io  port  entry  (bit  (8)  .bit  (8)  ), 
er.abre_cpu_interrupts  entry, 

/*  used  to  overlay  the  fixed  bin(7)  parameter  #/ 
cnt  bit(9)  based ( byt_cnt_pt r) , 
byt_rnt_ptr  pointir, 

disatle_cpu_interrupts  entry, 

low  by t-cnt~f ixed  bin'7), 


vrite_bar  entry  (pointer)* 


call  disatle_cpu_interrupt s : 

do  while  (copy_ie_register  =  transmi t_dma_done 

t 

copy_ie_regi ster  =  recei ve_dma_done ) * 
call  enable_cpu_interrupts 5 

do  while  (copy_Ie_register  =  transmit_dma_done 
copy_ie_register  =  recei ve_dma_dore ) ; 

end  * 

call  disable_cpu  interrupts » 

end: 


copy_ie_regis ter  =  disable_ni3010  interrupts* 
call  vrite_io_port (interrupt_enable_register , 

disable_ni3010_interrupts ) i 

call  enable_cpu  interrupts* 

call  write_bar  Taddr( transmit_data_block) ); 

call  write_io_pcrt (high_byte_count_reg ,  '00 'b4) ; 

/*  increment  the  parameter  and  overlay  it  */ 
low_byt_cnt  =  low_byt_cnt  *  14? 
byt~cnt_ptr  =  addr(low_byt_cnt) ; 
call  wri te_ic_port ( low~byti_count_reg, cnt ) ; 

call  ii satle_cpu_interrupts* 

copy_ie_reglster  =  transmit_dma_done ; 

call  write_io_port ( inter rupt_enable_regi ster  , 

transmit_dma_done)  * 
call  enable_c pu_interrupts 

do  while  (copy_ie_register  =  transmit_dma_done ) ; 
end;  /*  loop  until  the  interrupt  handler 
takes  care  of  the  TDD  interrupt  - 
it  sets  IE_RB3  to  4  */ 

call  perform_command(load_and_send) ; 


end  transmit_packet * 


This  nodule  is  called  by  the  assembly  language  interrupt 
routine.  It  handles  three  ni3013  interrupts:  the  receive 
block  available,  receive  dma  done,  and  the  transmit  ima 
done  interrupts.  It  also  checks  for  the  r.i3313  size 
anomally?  if  found,  it  prints  out  an  error  messsage  and 
terminates  the  program.  If  a  packet  is  received  from  the 
VAX,  the  variable  ' seg_ack"  is  updated  so  that  the  outgoing 
packet's  acknowledgement  number  can  be  updated  in  the 
remote_login  module.  The  variable  "size'  is  overlaid  on  the 
frame  length  of  the  ethernet  packet;  it  is  the  length  from 
the  first  destination  byte  to  last  CRC  byte;  it  is  used  to 
reposition  the  receive_data_block  in  memory  so  that  r.o 
portion  of  th  previous  packet  is  overwritten.  tohen 
examining  the  packets  in  memory  with  DDT-86,  each  will  be 
separaed  by  the  asteriks  that  were  used  to  fill  a  large 
portion  of  the  extended  tpa. 


EL_interrupt__handler : 


procedure  external; 


declare 

source  bit(8)  external, 
wri te_io_port  entry  (bit  (8)  ,bit  (8)  ), 
read_io_port  entry  (bit  (8)  ,  b i t ( 8 )  ), 
enable_cpu_interrupts  entry, 

user  jles ires  fixed  external, 
4isable_cpu_in terrupts  entry. 

write_tar  entry  (pointer); 


call  disable  cpu  interrupts? 

call  wri te_io_po? t ( interrupt_enable_register , 

d is able_nl3010_ in terrupts ) ? 
if  (copy  ie_register  =  receive  block  available) 
then  do?“ 

/*  gives  address  to  board  for  next  dma 
of  packet  into  memory  */ 

call  write_bar(addr( recei ve_data_block) ); 
call  wri te_io_nort ( high_byte_count_reg,  '36'b4); 
call  wri te_io_port ( low_byte_coun t_reg , '30 'b4) ; 

/*  initiate  receive  DMA  */ 

copy_ie_register  =  recei ve_dma_done  ; 

call  write _io_port( in terrupt_enable_register , 

recei ve_dma_d one ) J 


end;  /*  if  receive=block_avai lable  */ 


%  *.  #N  *. 


else 


if  (cony  ie  register  =  receive  dma  lone)  then 
do ; 

numter_of_packets=r.umter_of_packets  +  l; 

size  ptr=  addr ( recei ve_data  bl ock .f rame_ler*th  lsb); 
if  (size  >  1522  !  size  <  647  then 
do ; 

put  skip  list(  'SIZE  ERROR'); 
stop; 
end? 

source  =  '00 'b4; 

If  (receive_data_block. source_address_f  =  vax)  then 
do; 

source  =  vax» 
do  i  =  1  to  4; 

seg_ack(i)  =receive_data_block.data ■ i  +  24) 
end ; 
end; 

rec_blk_ptr  =  addr ' recei ve_data_block. data (size-*) ) ; 
copy_ie_register  =  rereive_block_available ; 
call  wr!te_io_port 'interrupt_enatle_register , 

recei ve_bl ock_a vail able ) ; 

end?  /*  if  receive  dma  done  */ 

else 

if  (copy  ie_register  *  transmit_dma  done) 
then  Io;~ 

copy_le_register  *  receive_block_availableJ 
call  write_io_port 'interrupt_enable_regi ster , 

recei ve_bl ock_ava il abl e ) ; 

end;  /*  if  transmit  dma  done  */ 


end  HL_interrupt_handler ; 


102 


This  nodule  is  called  from  the  remote_login  module.  It 
calculates  the  checksun  for  the  TCP  header.  Since  the 
calculation  involves  ait?seudo  header  prepended  to  the  TCP 
healer,  the  variable  "temp"  stores  all  the  bytes  of  memory 
located  just  prior  to  the  TCP  header  (that  it,  the  last  12 
bytes  or  the  IP  header).  Overlays  are  used  that  bit(S) 
values  can  be  used  as  integer  values  without  suffering  from 
conversion  factors.  The  variable  "int_length'  is  the  length 
of  the  IP  dtatgram  and  therefore  includes  the  TCP  segment. 
The  variable  ”seg_len"  is  the  length  of  the  TCP  segment.  If 
the  length  of  the  segment  is  an  odd  number,  then  an  extra 
null  byte  is  added  so  that  there  are  full  16  bit  words  for 
the  checksum  calculation.  NOTE:  the  divide  function  is 
used?  it  returns  the  floor  value  should  there  be  a 
remainder  from  the  division. 


calc_tcp_cksum : 


procedure  ; 


del 

cksum  entry  (bit (8) .fixed  bin ( 7 ) ,bi t ( 16) ) , 
fixed_overlay  bit(8)  based(fixed  overlay_ptr ) , 
fixed_overlay_ptr  pointer, 

int_length  fixed  bin(7)  based( int_length_ptr) , 

int_length_ptr  pointer, 

numl6bit  wds  fixed  bin(7), 

odd  bit(l),  /*  odd  IP  length  */ 

temp( 13 )  bit(S); 


odd  =  false; 

do  i  *  1  to  12;  /*  save  last  12  bytes  of  I?  header  #/ 

temp(i)  =  transmit  data  block. data(i  +  6); 

end? 


/*  form  tep  PSEUDO  HEADER  */ 


transmi t_data_block 
transmi t_data_block 
transmi t_d a ta "block 
transmi t_data_block 
transmi t "data _ block 
transmi t~da  ta "block 
transmi t_d a ta ^b lock 
transmi t_data_block 
transmit^data^block 
transmi t_dat a _block 
transmi t "data "block 


.data (9 ) 

= 

'c0  'b4 ; 

.da  ta (10) 

= 

'09'b4; 

.da  ta ( 11 ) 

= 

'c9'b4J 

.data ( 12) 

= 

'01  'b4; 

.data ( 13) 

= 

'ce'b4J 

.data ( 1 4) 

= 

'09  'b45 

.da  ta ( 15) 

= 

'c3'b4; 

.data (16) 

= 

'03'b4J 

.da  ta ( 17 ) 

= 

'00'b4! 

.da  ta (18) 

= 

'06'b4; 

.da  ta ( 19) 

= 

'70  'b4J 
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■  i '  I,"*.' 


/*  overlay  bit(8)  with  fixed  value  3(1  / 
int_length  ptr  =  addr (internet_header .length_lsb ) ; 
seller  =  TInt_length  -  20); 
uumlehi t_wds  =~divide(  ( i.nt_length  -  8), 2,7); 

/*  check  if  lensth_is  odd  number  of  bytes  #/ 
if  (  nod ( seg_len ,2 )  ”=  0  )  then 
do ; 

odd  --  true? 

numlobit _wds  =  numl6hit_wds  +  15 

ternp(13)  =  transmit_data_block.data ( int_length  ■*■1)* 
transmit  data  block .data (int  length  +1)  =  '00'b4J 
end » 

/*  insert  byte  12  of  pseudo  header  */ 
fixed_overlay_ptr  =  addr ( seg_len ) 5 
transmit_data_block.data(20)  =  f ixed_overlay ; 

call  cksum(transmit_data_block.data(9), 

numl6hit_wds , tcp_header .checksum ) ; 

/*  restore  I?  *? 
do  i  =  1  to  12; 

transmit  data_bl ock .data ( i  +  8)  =  temp(i); 

end; 

if  odd  =  true  then 

transmit_data_block. data ( int_length  +1)  =  temp(13); 


end  calc_tcp_cksam; 


/  siesjtJjc *#*# *###**** *******  / 

This  module  sends  the  packets  necessary  for  the  connection 
es talishment  to  the  VAX  and  the  remote  login  protocol  up  to 
the  point  where  the  7AX  asks  for  "Password”.  lach  packet 
update  changes  only  those  portions  of  the  packet  that  are 
different  from  one  packet  to  the  next.  There  is  no 
processing  of  inbound  packets  except  for  VAX  seauence 
numbers  and  data  to  be  pushed.  It  assumes  no  deviation  from 
a  normal  login  sequnece. 

**********************************************************  / 
remote_login :  procedure? 

declare 

source  bit(8)  external, 
packet_length  fixed  bin(7)  external, 
add32bit  entry  ( bit ( 9 ) , bi t ( 8)  ,b i t (8 ) ) , 
cksum  entry  (bit(8) .fixed  bin (7 ) , bi t ( 1 6) ) , 
wri te_io_port  entry  (bit  '8)  ,bit  (8)  ), 
numlCbit  vds  fixed  bin(7)  external; 


'lyj&'&L- 


/V-viv: 
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/*  send  packet  1  */ 
r.u*"16bi  t_wds  =  12? 

call  cksum  ( interne t_header  .versi  on_ihl  ,r.uml6bi  t_wds  , 

intemet_header . hdr_checksum ) ; 
call  calc_tcp_c ksum? 
packet_ler.sth  =  46> 
call  transmit_packet ( packet _length) ; 


/*  assume  VAX  will^acknowledee  it  #1,  wait  until  it  does  V 

do  while  (  source  ~=  vax  ); 

end; 


/*  packet_2  update  #/ 
inc_seo_num (4 )  =  '31 'b4; 

call  add32bit 'tcp_header . sequence  num (4 )  ,  inc_sea  _num  (4 ) , 
tcp_header . seauence_num ( 4l } 5 
tcp_header . of f set  =  '50'b4»~ 
tcp_header .control  =  ack; 

call  add32bit:'seg  ack(4),inc  sea  num  (4) ,  tcp_header  .ack  num(4)); 
internet_header .len«th_l sb  =  '28^4; 
internet  header. id  isb  =  '02'b4J 


/*  end  packet_2  update  V 
numl6bit_wds  =  12; 

internet'header .hdr_checksum=  '0300'b45 

call  cksum( internet_header .versi on_ihl ,numl6bi t_wds , 

internet_header .hd r_checksum ) ; 
tcp_header . checksum  =  '0000  'b4J 
call  calc_tcp_cksum; 
packet_len£th  =  46! 
call  transmit_packet ( packet_len^th) ; 


/*  packet  3  update  #/ 

internet_header . length_l sb  =  '29'b4; 
tcp_header  .control  =  ack  psh*’ 
tcp~header  .data  1 )  =  '00"’'b4> 
tcp_header .da ta (2 )  =  '04'b4; 
tcp_header .da ta ( 3 )  =  '04'b4; 
tcp_header .data(4)  =  '00'b4I 
tcp_header.data(5)  =  '00'b4; 
t cp_header .da ta (6 )  *  '00'b4I 


-  .  *  .  •  s  v  -  .  ^  I  V 


pHt-ii  m  ,mi 


internet_header . id_lsb  =  '93'b4; 
numl6bit_wds  =  10? 

i nterne t_heai sr  .hdr_checksum  =  ''22-22'' b 4  ? 

call  cksum(  internet  "header  .vers  ion_i  hi  ,numl6bi  t 

in t  ernet _header . hdr_checksum ) ; 
tcp  header . checksum  =  '222 0'b4? 
call  calc_tcp_cksum; 
packet_length  =  46; 
call  transmi t_ packet ( packet _lergth ) ; 


/*  packet  4  update  */ 

interne t_header .length_lst  =  '2e'b4; 
inc_seq_num(4  )  =  '01  'b4l 

call  ad532bit  (tcp_header  .  sequence_num(4)  ,  ir.c_seq 

tcp_header . sequence_num( 4 ) )  > 

tcp_heaier  .da ta  '  1 )  =  '72'b45 
tcp_header . data (2 )  =  '65'b4J 
t cp_header . da ta ( 3 )  =  '65'b4; 
tcp_header .da ta (4 )  =  '6b'b45 
tcp_header .data(5)  =  '65'b45 
tcp_header.data(6)  =  '00'b4J 

internet_header . id_lsb  =  '04'b4J 
numl6bit~wds  =  10  ? 

interne t~header .hdr_checksum  =  '0000'b4J 

call  cksum( in t ernet _header . version _i hi ,numl6bit_ 

internet  header. hdr  checksum); 
tcp_header .checksum  =  '0000'b4J 
call  calc_t cp_cksum; 
packet_length~=  46; 
call  transmit _packet (packet _1 eng th ) ; 


/*  segment  5  update  */ 
inc_seq _num (4  )=  '06'b4J 

call  ad 432b i  t  ( tcp_header  .  seauer.ce_nun( 4)  .  inc_seo 

tcp_header . sequence _n urn ( 4  ) )  *  ~ 
interne t_header . id_lsb  =  '05'b4J 
numl6bit_wds  =  10  J 

internet_header .hdr_checksum  =  '0000  'b45 

call  cksum( in t ernet _header .version_ihl fnuml6bi t_ 

int ernet_header .hdr_checksum ) ; 
tcp_header . checksum  =  '?000'b4; 
calf  calc_tcp_cksum; 
packet_length~=  465 
call  transmi t_packet(packet_l eng th); 


wds  , 


num (4)  , 


wds , 


num (4)  , 


wds , 
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/*  packet  6  update  */ 


internet_header.lensth_lsb  ='31 'b4; 
inc_seq_num  '4  )=  '06  'b4i 

call  ad 432 bi  t  ( t  cp_heaier  .  sea  uence_nu.""(  4)  ,  inc_sea  _num  '  4 } 

tcp  header . seauence  num'4)); 
internet_header. id_Isb  =  '06'b4»* 

tcp_header .data ( 1 )  ='73'b4f 
tcp_header .data (2)  ='75'b4; 
tcp_header .data(3)  ='6e'b4J 
tcp_header .data (4)  ='2f'b4J 
tcp_header.4ata(5)  ='39'b4; 
tcp_header .data (6)  =  '36'b4J 
tcp_header .data (7 )  ='30'b45 
tcp_header.data(8)  ='30'b4J 
tcp_header .da ta (9  )  =  '00'b4; 

numl6bit_wds  =  10 » 

interne t_header .hdr_checksum  =  '0000  'b4; 

call  cksum (  in  ternet_header  .version_ihl , numlSbi t_wds  , 

internet_header .hdr_checksum  ) ; 
tcp_header . checksum  =  '0£00'b4i 
call  calc  tcp_cksum? 
packet_length  =  49? 
call  transmit_packet (packet_len*th) ; 


/*  wait  unti  vax  replies  */ 

do  while  (source  "'=  vax); 
endi 


/*  wait  until  vax  replies  with  Its  null  byte  */ 

do  while  (  (source  =  vax)  & 

( receive_data_block.da ta (34)  ~=  ack_psh)  ); 

end ; 


/*  packet  7  uodate  */ 

interne t_header . length_lsb  =  '28'b4* 
inc_sea_num (4 )=  '09'b4; ~ 

call  add32bi t  ( t cp_header . sequence_num( 4) , inc_seq_num (4 ) 

tcp_head er . seouence_num( 4 ) ) ; 
lnc_seq_num (4)='01'b4» 

call  add3?bi t ( t cp_header . ack_num ( 4 ) , inc_seo_num ( 4 ) , 

tcp_header .  ack_num(4  ) )  ; 
tcp_header .control  =  ack? 
interne  t  header .  id_lsb  ='07'b4! 
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Command  Function  Cedes  */ 


module_in terf ace_loopback 

internal_loopback 

clear_l oopback 

go_of fline 

go”online 

onboard _di agnostic 
load_transmit_data 
load~and_send~ 
reset 

set_promiscuous_mode 
clear  insert  source  address 


by  '0l'b4, 
by  '02'b4, 
by  '03'b4, 
by  '08'b4, 
by  "09'b4, 
by  '0a'b4, 
by  '2£'b4, 
by  '29'b4, 
by  '3f'b4, 
by  '04'b4t 
by  '0e'b4? 


end  Command  Function  Codes 


f* a  •*. 


s  >*  / 


/*  These  4  element  arrays  are  32  hit  variables 


%/ 


inc  seq  num(4)  bit(S), 
seg“ackT4)  bit(a); 


^replace 

/*  Control  bit 
ack 

ack_psh 

syn~ 

ack_fin 

ack~syn 


for  the  TCP  header  */ 

by  '00010000 'b, 
by  '00011000 'b , 
by  '00000010  'b , 
by  '00010001  'b , 
by  '00010010  'b , 


/*  I/O  port  addresses 

These  values  are  specific  to  the  use  of  the  INTERLAN  NI3010 
MULTIBUS  to  ETHERNET  interface  board.  Any  change  to  the  I/O 
port  address  of  '2T0b0 '  hex  (done  so  with  a  DIP  switch)  will 
require  a  change  to  these  addresses  to  reflect  that 

change . 

*/ 


command_register 

by 

'b0'b4, 

command ~status_register 

by 

'bl 'b4 , 

transmit_data_re*ister 

by 

'b2'b4, 

interrupts  tatus_r  eg 

by 

'b5'b4, 

interrupt_e.nable_register 

by 

'b3'b4, 

high_byte_count_reg 

by 

'be 'b4, 

low_byte_c ount_reg 

by 

'bd'b4. 

/*  end  of  I/O  port  addresses  */ 


/*  Interrupt  enable  status  register  values  V 


disable_ni3010_lnterrupts 
nl3010_Intrpts_disabled 
receive_block_ava liable 
transmi t_dma_done 
receive_dma_done 

/*  end  register  values  */ 


by  '00'b4, 
by  '00'b4, 
by  '04'b4, 
by  '06'b4, 
by  '07'b4, 
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APPENDIX  E 


INCLUDE  FILE  FOF.  PROGRAM  DEMO 


decla  re 


internet_header  based 
2  version  ihl 


2  type_of _service 
2  length_msb 
2  len*th-lsb 
2  id_m$b“ 

2  id  lsb 
2  flags_fras 
2  ttl 
2  protocol 
2  hdr_checksum 
2  source_a 
2  source_b 
2  source~c 
2  source_d 
2  dest_a~ 

2  dest~b 
2  dest~c 
2  dest  d 


(int  hdr_ptr), 

bit (8) , 

bit (8)  , 

bit ( 8) , 

bit (8) , 

bit (8) , 

bit (8) , 

bit  (16-) . 

bit ( 8 ) , 

bit (3 ) , 

bit (16) , 

bit (8) , 

bi t ( 8 )  , 

bit (8 ) , 

bit (3) , 

bit ( 3 ) , 

bit(8) , 

bit(3) . 

bit (8 ) , 


1 

tcp  header  based(tcp  hdr  ptr) 

2 

source_port 

bit(16) , 

2 

des  t_por t 

bit ( 16 ) , 

2 

sequence_r.um(4 ) 

bit (3) , 

2 

ack_num(4) 

bit (8)  , 

2 

offset 

bit (8 )  , 

2 

control 

bit (8) , 

2 

vindov_msb 

bi t ( 3 ) , 

2 

window_lsb 

bit (9) , 

2 

checksum 

bi  t ( 16 )  , 

2 

urgent_pointer 

bit ( 16) , 

2 

data ( 512) 

bit (8 )  . 

int_hdr_ptr 
tcp~hdr  ptr 
seg“len“ 
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pointer, 
pointer , 
fixed  bln (7 )  , 


APPENDIX  G 


INCLUDE  FILE  FOR  PROGRAM  LISTEN 


%replace 


/* 


I/O  port  addresses 


These  values  are  specific  to  the  use  of  the  INTERLAN 
NI3010  MULTIBUS  to  ETHERNET  interface  hoard.  Any 
change  to  the  I/O  port  address  of  '0?b0'  hex  (done 
so  with  a  DIP  switch)  will  reauire  a  change  tc 
these  addresses  to  reflect  that  change. 

#/ 


command_register 
command_s  tatus_regi ster 
transmi t_data_register 
interrupt_sta tus_reg 
i n terrupt_e nab le_regi ster 
high  byte_count_reg 
law_Syte_count_reg 


by 

'b0 

'b4, 

by 

'bl' 

>4, 

by 

'b2 

b4. 

by 

'b5 ' 

'b4. 

by 

'b8 ' 

”b4 , 

by 

'be  ‘ 

'b4. 

by 

'bd 

b4 , 

/*  end  of  I/O  port  addresses  */ 

/*  Interrupt  enable  status  register 
disable_ni3010_i nterrupts 
ni3010_in  trpts_disabled 
receive_block_available 
transmi t_dm a _d one 
receive  ima  done 


r  i 

/alue 

s  */ 

by 

'00' 

b4. 

by 

'00' 

b4, 

by 

'04' 

b4, 

by 

'06 ' 

b4, 

by 

'07' 

b4. 

/*  end  register  values  */ 

/*  Command  Function  Codes  */ 

module_interf ace  loopback 

internal_locpbac!c 

clear_loopback 

go_offline 

go^online 

onboard_dia gnostic 
load  transmit  data 


by 

'01  ‘ 

;b4. 

by 

'02  ‘ 

b4, 

by 

'03' 

'b4. 

by 

'08' 

'  b4. 

by 

'09' 

’b4 , 

by 

'0a  ‘ 

’  b4. 

by 

'28' 

b4, 
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side  of  the  16  hit  registers  in  the  8286  micro-processor  and 
the  second  byte  loaded  into  the  high  side  of  the  registers. 


EXAMPLE  OF  CALL  TO  TEIS  PROCEDURE 
call  cksum(x ,y, z)  where: 

parameterl  (hit  (8))  is  the  starting  hyte  of  data 

to  he  summed 

parameter2  (fixed  bin  ?)  is  one-half  the  length  of 

the  block  (#  of  16  hit  words) 
parameters  ( bi t ( 16 ) )  the  resultant  16  hit  checksum 

The  dx  register  will  contain  the  resultant  checksurt. 


public  cksum 


cksum: 


cseg 

push 

ax!  push  bx! 

push  cx!  push  dx!  push  si! 

mov 

mov 

si ,2  [bx] 
cx,  [si] 

•load  cx  with  one-half  the 

length 

mov 

ch,00h 

Jzero  out  high  side  of  cx 

register 

mov 

dx,0000h 

Jzero  out  running  total  of 

checksum 

mov 

clc 

si ,  [bx] 

•  si  points  to  first  byte  of  block 

again : 

mov 

al » [si] 

Jmsb 

of  16  bit  word 

inc 

si 

mov 

ah,  [s  1] 

;isb 

of  16  bit  word 

adc 

dx  ,ax 

» add 

to  running  total 

inc 

si 

loop 

aga  in 

xor 

dx, fffffh 

Jl's 

complement  of  running  total 

mov 

si ,4 [bx] 

•place  result  in  return  parameter 

mov 

[si] ,dl 

APPENDIX  P 


CHECKSUM  PROGRAMMING  NOTES  AND  SOURCE  CODE 
The  checksum  algorithm  for  the  IP  header  and  the  TCP 
segment  are  the  same.  The  official  specification  for  the 
algorithm  is: 

The  Checksum  field  is  the  16  hit  one's  complement  of 
the  one's-  complement  sum  of  all  16  hit  words;  for 
purposes  cf  computing  the  checksum,  the  checksum 
field  is  zero.  [Ref.  3] 

Another  source  lists  the  algorithm  as: 

The  checksum  field  is  to  simply  add  up  all  the  data 
regarded  as  16  hit  words,  and  then  to  take  the  one's 
complement  of  the  sum.  [Ref.  6] 

The  assembly  language  program  below  always  agreed  with  the 
checksum  calculations  that  were  contained  in  the  packets. 
Initial  attempts  yielded  inconsistent  reults  when  compared 
to  those  in  the  UNIX  produced  packets.  Some  attempts  always 
produced  the  correct  result  for  the  IP  header  and  9V%  of  the 
time  for  the  TCP  header.  Other  attempts  were  less 

consistant  than  the  above  example.  Since  one's  complement 
arithmetic  is  used,  the  erroneous  implementations  can 
produce  results  that  are  Quite  close  to  those  produced  by 
the  UNIX  operating  system. 

The  program  below  implements  the  algorithm  as  if  the  16 
bit  words  were  integers  stored  with  the  least  significant 
byte  in  low  memory,  followed  by  the  most  significant  byte. 
Note  that  the  first  byte  of  the  word  is  loaded  into  the  low 


.byte  of  first  number  to  add 
Jbyte  of  other  number  to  add 


mov 

al  f  fsij 

mov 

ah,  [dil 

adc 

ah  ,al 

dec 

si 

push 

si 

mov 

si  ,dx 

mov 

[si]  .ah 

dec 

si 

mov 

dx  ,si 

pop 

si 

dec 

di 

loop 

beg 

Jdecrement  pointer  and  store  it  away 

•make  si  now  point  to  result 
.move  addintion  into  result 

istep  down  in  memory 
Jsave  pointer  to  result 


pop  di!  pop  si!  pop  dx!  pop  cx!  pop  bx !  pop  ax! 


APPENDIX  E 


SOURCE  CODE  FOR  32  BIT  ADDITION 
EXAMPLE  OF  CALL  TO  THIS  PROCEDURE 

call  add32bit (numberl (4) ,number2(4) .result (4) )  where: 

parameter  1  is  the  least  significant  byte  of  a 
32bit  number  (array  of  4  bytes) 
parameter  2  is  the  lsb  of  another  32  bit  number 
parameter  3  is  the  lsb  of  the  result 


The  32  bit  numbers  are  stored  in  memory  such  that  the  high 
order  byte  occupies  the  lowest  memory  location.  This  is 
contrary  to  the  way  that  PL1  stores  numbers.  The  numbers 
are  stored  in  this  manner  because  they  have  been  BMA'd 
into  memory  by  the  NI3010  board  in  the  order  they  were 
recieved  over  the  Ethernet,  i.e.,  high  order  byte 
recieved  first. 

The  algorithm  adds  the  numbers  byte  by  byte  starting  with 
the  low  order  bytes  and  places  the  rseultant  byte  addition 
into  the  corresponding  result  byte  position. 


public  add32bit 
add32bi t : 


cseg 


push  ax!  push  bx!  push  cx!  push  dx !  push  si!  push  di  ! 


mov 

cx , 04 h 

mov 

mov 

mov 

si ,  [bx] 
di , 2  [bx] 
ix,4[bx1 

Jrumber  of  bytes  to  be  added 
J (32  bit  number) 

Jload  index  registers  with  address 
;the  lsb  of  each  number  to  be  added 
Jpointer  to  the  lsb  of  the  result 


tcp_header  .data ( 1 )  ='2f'b4* 
t cp_header  . da  ta  (2 )  ='29'b4; 
tcp_header  .da  ta  '3 )  ='36'b4; 
t'cp_header  .data  'A)  =  '30'b4; 
tcp_header .data(5)  ='30'b4J 
tcp_header .da ta \6 )  =  '00'b4i 

numl6bi t_wds  =  10* 

internet~heaier  .hdr_checksum  =  '0000'b4* 

call  cksum{  in  t erne t "header  .  vers  ion_ihl  ,numl6bi  t.  wds  , 

internet_header .hdr_checksum ) » 
tcp_heaier .checksum  =  '0000 "b4; 
call  calc_tcp_cksum * 
packet_length  =  46? 
call  transmit_packet(packet_length) ; 


put  skip  list  (  'PACKET  #7  SSNT'); 
put  skip; 

do  while  ( number_of ^packets  <  user_desires  )* 
end;  /*  do  while  */” 


end  remo te_login ; 
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